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

[William Salmon <will salmon codethink co uk>]

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.

> As Jurg points out the tracking behavior is very specific, and not 
> necessarily intuitive.  I think having a UI where a tracking
> branch and additional branches are configured differently but are 
> considered equivalent is not great.

I think Tom has plans to work out Jurgs comments so i will ignore this.

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

That said

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.

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.

> Would you expect the same behavior implemented in other core source SCM 
> plugins?

All our plugins have some differences in tracking as mandated by the 
underlying programs actual behavior. But maybe if a user of a different 
plugin likes the git way then they could add the optional feature too, 
given this is a additive change I don't think this should block the 
change in git.

A lot of work has gone in to making a consistent CLI and this seems to 
have been broadly positive. And making plugins less consistent seems bad 
especially for required fields but all our plugins have slightly 
different bst fields as the underlying programs are different.

> Cheers,
>
> Sander
>
> On Tue, Jan 14, 2020, 18:43 Jürg Billeter <j bitron ch 
> <mailto:j bitron ch>> wrote:
>
>     Hi Tom,
>
>     On Mon, 2020-01-06 at 15:22 +0000, Tom Mewett via buildstream-list
>     wrote:
>      > [...]
>      >
>      > [!1774]
>      > https://gitlab.com/BuildStream/buildstream/merge_requests/1774
>      >
>      > The main additions to 'git_tag' are:
>      >
>      > 1.  It will fetch only the given ref when given an exact tag ref
>      >     (*-0-g*)
>      > 2.  It can be configured to choose the latest tagged commit when
>      >     tracking
>      > 3.  It can track multiple branches; it chooses the latest
>      >     commit/tag found on any when tracking
>      >
>      > As I see it, (1) and (3) are uncontroversial and could be added right
>      > away. I welcome any comments on this.
>
>     Can you please elaborate on the use case for (3)? I can't currently
>     think of a scenario where tracking the latest commit/tag from multiple
>     branches (by comparing commit dates) would be useful and robust.
>
>     If you specify multiple release branches that are all being maintained
>     or master + a release branch, wouldn't this risk `bst source track`
>     jumping between branches?
>
>     E.g., let's say we're tracking master and a release branch (1.8). A
>     release is tagged in the release branch, 1.8.2. `bst source track` will
>     use that tag. On the next day 1.9.1 is tagged in master. `bst source
>     track` will thus switch to 1.9.1. A week later the release branch gets
>     a bugfix release, 1.8.3. Now `bst source track` will switch from 1.9.1
>     to 1.8.3, which doesn't make sense to me.
>
>     Is there a way this feature can be used without this issue?
>
>     I did suggest tracking of multiple branches in #220 almost two years
>     ago, however, with a difference. I suggested the list of branches to be
>     considered candidate branches and the first branch that exists would be
>     tracked. The idea of this was that it would allow specifying release
>     branches that haven't been created yet. This should be more robust
>     (assuming the upstream project does not delete release branches).
>
>     Cheers,
>     Jürg
>
>     _______________________________________________
>     buildstream-list mailing list
>     buildstream-list gnome org <mailto:buildstream-list gnome org>
>     https://mail.gnome.org/mailman/listinfo/buildstream-list
>
>
> _______________________________________________
> buildstream-list mailing list
> buildstream-list gnome org
> https://mail.gnome.org/mailman/listinfo/buildstream-list