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

[Sander Striker <s striker striker nl>]

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.

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

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

Cheers,

Sander

On Tue, Jan 14, 2020, 18:43 Jürg Billeter <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
https://mail.gnome.org/mailman/listinfo/buildstream-list