Re: [BuildStream] Merging 'git_tag' and 'git'

[Benjamin Schubert <contact benschubert me>]

Hi


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, 16 January 2020 10:56, William Salmon via buildstream-list <buildstream-list gnome org> wrote:

> On 14/01/2020 18:50, Sander Striker via buildstream-list wrote:
>
> > Hi,
> > I'm not convinced we want to reconsolidate got and git_tag plugins.  I'm
> > primarily worried about feature creep, maintaining an intuitive and
> > consistent UI at least when it comes to the CLI and "core" plugins.
>
> I'm pretty confused by`maintaining an intuitive and consistent UI`,
> given its my understanding that all Tom's changes are only additive (I
> don't think behavior will change unless turned on in the bst file) and
> as far as I understand do not effect CLI at all.

UI doesn't stop at the CLI. When writing a BST file, you will need to know
a bit around the plugins that you are using. Having plugins _with vastly
different behaviors_ depending on their configuration is unintuitive and
prevents knowing at the first glance what is happening for your element.

I strongly believe our source plugins should each have a single tracking
mechanism, each.

If the problem here is that implementing new plugins that are similar to
previous one but for a few differences (e.g. tracking), we should strive
to make it easier for plugin authors to write those plugins.
We had started the work there with the 'DownloadableSourceBase'
and the 'GitSourceBase', but never completed it.

> > I think that projects will end up with different tracking strategies and
> > I wonder by implementing one should we implement them all?  Or keep
> > [git] tracking simple and leave complex tracking external
> > (e.g.manipulating .bst files directly based on project specific setups)
> > or to specialized plugins?
>
> I also think given both freedesktop and gnome meta who both have a lot
> of users have both chose to use the git_tag plugin lends weight to the
> already good idea of allowing you to only track releases. But so long as
> those contributing are willing to maintain there patches I don't really
> see a issue with supporting a number of entirely optional strategies.

I don't recall anybody saying the git_tag plugin should not exist.
It _is_ a valid tracking mechanisme for _some_ projects. We should
ensure however that users of other plugins (git) are not impacted in
their usability by plugins that try to do many things.

> A lot of work has been put in to allowing plugins to live out side of
> build stream and i am generally in favor of effort being put in to
> allowing plugins to be very good citizens, I think effort would be
> better put in to making it easier to use external plugins than moving
> functionality in to core.
>
> But I did not think we as a community had said that this needs to stop
> the most useful features of plugins that extend core plugins being move
> in to core.
>
> The model hear of successfully maintaining and developing external
> plugins and then picking there most commonly used features in to core
> seems like a very sensible model to me.

We had decided to move _all_ plugins (feasible, we still need local/junction)
outside of core. Why then try to merge too many things into one?


> Given that in our consensus of silence Tom had done all the work I think
> we should merge these changes, once Jurgs comments have been addressed.

This is not a valid argument, and some discussions had already been taking
place in IRC concerning this exact concern, even before the ML post was
posted.

Let me be clear: no, the work from Tom is not useless. I strongly believe we
should merge the improvements to the gitsourcebase that were discovered while
working on this merge.

However I am still against merging both git and git_tag, as they would not
be presenting a simple, consistent UI.