Re: [BuildStream] Merging 'git_tag' and 'git'
- From: William Salmon <will salmon codethink co uk>
- To: buildstream-list gnome org
- Subject: Re: [BuildStream] Merging 'git_tag' and 'git'
- Date: Thu, 16 Jan 2020 10:56:09 +0000
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]