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

[Tom Mewett <tom mewett codethink co uk>]

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?

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

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>
- Another notable project, GNOME Build Meta, also uses 'git_tag'
  exclusively <https://gitlab.gnome.org/GNOME/gnome-build-meta>

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>

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

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

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

-- 
Tom Mewett <tom mewett codethink co uk>