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.
Of course. Thank you for coming back to this.
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.
For an intuitive experience, even though tools underlying source plugins may differ, it is desirable to get a certain predictable behavior when running `bst track`. Similarly configuring source plugins should be straightforward and close to what the underlying tool provides. I should be able to determine behavior by just looking at the .bst file without looking at documentation; the distinction between the 'git_tag' and 'git' kinds is actually useful in this respect.
> 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.
Warning: random grumbling follows
Apparently _gitsourcebase.py already does more than I thought it did. The
'track-tags' feature I personally think is already taking it too far. Naming wise
it's not super intuitive that it only tracks to tags on the tracking branch.
The submodule configuration is duplicating information that is in the
submodule configuration in-repo; it should be more straightforward to configure either
which urls to disallow for submodules or which subdirectories - both seems
redundant. I could be wrong, but submodules would probably be implemented
more like a source transform today, to keep the complexity limited and scoped.
Now, that said, this is all water under the bridge. Expanding the track-tags with
match and exclude, which is how git does matching, doesn't strike as too much
in addition.
The git lfs additions I would consider splitting out into its own module - again for
scoping.
> 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.
It means that we are knowingly creating the possibility incompatible configurations. And that's simply not great in a number of dimensions.
Note that I have been pushing for a long time to also take a "remote only" perspective when looking at features. That is, consider not having any files locally when building un-modified source. Or, only require modified source to exist locally - typically in workspaces.
Conversely, having a "local only" perspective is good to have as well.
> > > 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.)
My perspective on this:
1. BuildStream is used to perform integration builds of multiple elements
2. The track functionality in BuildStream is a convenience function for developers to update to the latest source of an element (typically represented by a branch - which may be master)
3. When tracking released software there is a project specific protocol for which releases to pick - this is typically done best centrally, by a process that will push updates to the repository containing say a `project.refs` file. This does not necessarily have to use the bst client to update `project.refs`. Doing this centrally also reduces the amount of polling all repositories by all users that are tracking.
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.
Given the state of _gitsourcebase.py I'm adjusting to +0 on folding in the `match` and `exclude` changes.
Thanks for reading this far. I hope that gave you a bit more color and perspective.
Cheers,
Sander
--
Tom Mewett <tom mewett codethink co uk>
