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

[Tom Mewett <tom mewett codethink co uk>]

Hi Sander,

Please allow me to apologise for coming across in the way I did in my
previous email. You are right that I didn't consider a fair sample
of users -- I fell into that trap because I see only one kind of
use-case in my day to day. I hope you understand.

Realising that, I would still like to continue this discussion; I think
it would be useful, at least for me as a contributor, to understand the
philosophy of BuildStream.

On Wed, 15 Jan 2020 23:01:20 +0100
Sander Striker <s striker striker nl> wrote:
> 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.

I don't understand how this is relevant to the CLI; could you expand on
that? W.r.t core plugins, I agree that a consistent UI is certainly
desirable. However, the tools represented/used by the core plugins are
not the same, and are sometimes not even all that similar (Git vs
Bazaar) -- maintaining consistency of optional, extra features seems to
me like unnecessary caution, and could prevent the plugins from
being individually more useful.

> On Wed, Jan 15, 2020 at 1:47 PM Tom Mewett <tom mewett codethink co uk>
> wrote:
> > 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.

I agree. What I'm not so in agreement with currently, is that the
complexity of tag-tracking outweighs its utility as part of a default
Git source plugin.

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

Interesting -- I hadn't considered the implications of this on a wider
ecosystem of interacting tools. If the tracking part of Fetch API is to
be generic enough that it doesn't just cater to the BuildStream Git
source, then I agree it's sensible to have caution here. On the other
hand, it does sound like tag tracking would then become an optional
feature of an optional feature anyway, which sounds to me that it
doesn't require too much concern. I'm not familiar with this area
though.

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

> From my limited experience, I don't think it's incorrect to say:

1. One of BuildStream's common use-cases is to integrate released
   versions of software
2. The track functionality of BSt is used to update refs to newer
   versions
3. Software using Git commonly has tags for releases
4. Therefore, providing tag tracking supports (1) via (2) on the basis
   of (3).

(I don't mean to be in any way exclusionary with (1), it just reflects
what I've mostly seen from the tool.)

Naturally these are anecdotal and subjective points.

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

That is definitely the case. Thank you for all your comments so far.

-- 
Tom Mewett <tom mewett codethink co uk>