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

[William Salmon <will salmon codethink co uk>]

Ben

I take issue with some of the points bellow but that's not really the 
trust of what I was trying to say, so I will focus on that.

I was trying to say, dose the odd additive feature, really pose such a 
big threat to UI consistency?

> [...] We should
> ensure however that users of other plugins (git) are not impacted in
> their usability by plugins that try to do many things.

I would expect this response if we were changing how the plugin worked 
by default or changing the names of old options. But I am surprised that 
any one would be impeded in there use or understanding of the git plugin 
if the changes suggested were implemented.

> 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.

As far as I can tell the only effect these would have on users who are 
not interested in them is that there would be a few more lines in the 
doc labeled optional that they may or may not read. I cant think of how 
the new behaviors would effect how the plugin works other than the 
cadence of one of its features, or how that would cause confusion as to 
`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
> [...]

I would completely agree with this, however I am intrigued to hear that 
tracking with a different cadence falls in to this category.

I am interested in what aspect(s) of these addition features would have 
a negative impact on users of bst that were not interested in them?

Thanks
Will

On 16/01/2020 11:11, Benjamin Schubert wrote:
> 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.