Hi, thanks for your thoughts.
On Tue, 14 Jan 2020 19:50:17 +0100
Sander Striker <s striker striker nl> wrote:
> 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.
Who is "we" here? Has a discussion taken place or is this a personal
opinion?
I was being inclusive here and using "we" to refer to the BuildStream developer community in general. I then stated my concerns.
Assuming your issues extend further than those raised by Jurg, which I
plan to address, let me reply in general.
Whether a specific addition is feature creep or not is a subjective
issue.
To a point. I do note that you chose to only consider the first part and left out: maintaining an intuitive and consistent UI at least when it comes to the CLI and "core" plugins. Did you take offense at my use of the term feature creep?
Of course, it's important to consider, I don't take issue with
your concern. However, I think the claim is indefensible in the face of
features that are actually proven useful and desired by many real-world
users.
That's a bold claim :).
It's my opinion that if one refuses to provide highly-desired
features in the name of feature creep,then one is putting arbitrary
developer ideals before the needs of users.
Solely in the name of feature creep, I think I can grant you that :)
Now, highly-desired is not necessarily the best measure. You can find plenty of material linked to a "faster horse" on that.
And lastly, developer ideals are rarely arbitrary.
I'll leave that part for what it is for now.
Now, my claim that tag-tracking is highly desired needs
backing up.
- Freedesktop-SDK, arguably the flagship BuildStream project, uses
'git_tag' exclusively over 'git'
<https://gitlab.com/freedesktop-sdk/freedesktop-sdk>
That argument can be taken as polarizing and divisive - are you saying that freedesktop-sdk desires are to be valued differently? I'm sure you don't mean to alienate developers that have put their effort into this project that have little to do with freedesktop-sdk?
- Another notable project, GNOME Build Meta, also uses 'git_tag'
exclusively <https://gitlab.gnome.org/GNOME/gnome-build-meta>
Which is not surprising given it also depends on freedesktop-sdk. It's also not surprising because git_tag was authored by Valentin, fit for purpose. Note that back when it was authored there was a discussion prior to it, and there was the conscious decision not to put the functionality in the git source plugin. Have things truly changed, realizing the origins?
Several other smaller projects I've found or worked on also use
'git_tag'
- carbonOS <https://bitbucket.org/carbonOS/tree/src/master/>
- LibreML <https://gitlab.com/libreml/libreml>
- Rosey <https://gitlab.com/valentindavid/rosey>
- CRASH Jetbot System (similar to above)
<https://gitlab.com/celduin/crash/jetbot-system-bst>
All of these projects have something in common: they all depend on freedesktop-sdk. Then for a majority of the projects you listed here, I see the same subset of people in these projects. As such I don't see a fair sample of users here.
> 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 agree with this, and I plan to address this concern.
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?
I don't think tag tracking is particularly complex.
That doesn't really follow from the history here. I would argue that tracking a ref to a commit-ish is trivial. Anything beyond that comes with complexity, like it or not.
Are there any other
"tracking strategies" that you have encountered in usage? If another
"tracking strategy" became common and desired, would you be against
adding it?
I would want us to keep a broader perspective when considering, rather than focussing on a single use-case.
In addition to my stated concerns, I can also see this functionality impact future direction. I can see us leveraging the Fetch API[1] to implement SourceCache at some point in the future. I can also see us (optionally, through configuration) leverage the Fetch API for tracking, given a fetch through server that returns the commit id as a result qualifier. These additional constraints that git_tag offers would then need to propagate as qualifiers as well, and need to be supported server side.
> Would you expect the same behavior implemented in other core source SCM
> plugins?
Well, there is a lot of variation in how SCM tools work, so these
changes might not be transferable. But I would expect the plugins to
support common use-cases.
Let's consider that for a moment. Is this a common use-case? Is the branching and tagging pattern this functionality supports a common occurrence? Does this apply to other SCM's?
In closing, for reasons stated above I'm -0 on folding git_tag into git. I hope that I have caused you to see beyond the perception of me saying "no", and are considering more facets as a result of this thread.
Cheers,
Sander
--
Tom Mewett <tom mewett codethink co uk>
