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

[Chandan Singh <chandan chandansingh net>]

Hi all,

I think we are going a bit in circles on this thread. We have
discussed lots of high-level design principles and precise actions
together, which has made things more complex.

> From this conversation, my key takeaways so far have been:

1. There is general agreement that we should port improvements/cleanup
from git_tag to GitSourceBase, most of which Tom has thankfully
already done as part of
https://gitlab.com/BuildStream/buildstream/-/merge_requests/1808.

2. Conceptually, the only difference between the "git" and "git_tag"
plugins is the tracking mechanism.

So, regardless of what else we do, I think it would make sense to
attempt to base git_tag off of GitSourceBase and identify the
remaining differences. Once it reaches a point where the tracking
mechanism is the only difference, we can reconsider how the
code/configuration looks like then.

Hopefully this much is uncontroversial, and we can agree on it.

Rest of this message is my opinion on whether or not they should be separate.

---

First, I'd like to say the Git itself has no native concept like
"tracking" so whatever a BuildStream plugin does, it's a design
choice. As such, it's not a matter of representing the underlying tool
transparently.

Undoubtedly, there can be other tracking mechanisms, so do we want to
add more configuration options for those as well? We have experimented
with GitHub/GitLab specific git plugins in the past as well, should
they also be integrated into the same git plugin?

I don't think that's the right way to go. While _lots_ of plugins may
be confusing, I don't think we are close to having that problem. I
also think we don't need to be averse towards having multiple plugins
that are based off of similar underlying tools, but do different
things.

This does not mean that plugins can't share code or documentation.
Take `BuildElement` for example. It is the base class for the vast
majority of the element plugins. It provides some core functionality
which is documented in one place, so each plugin can just refer to it
rather than reproducing it. Can't we do the same for `GitSourceBase`?
I think the upstream implementations can share both code and
documentation.

For git_tag specifically, I won't expect needing to override anything
besides the `track()` method and partially `configure()` method.

> > I would also have one other question that I am still not clear with:
> >
> > If both plugins were living in the same repository and sharing the
> > bulk of the logic, would you see any other incentives in merging them?
>
> I don't have a issue with there being a few plugins for the same tool if
> its a lot easier to maintain some features separately.
>
> But you seem to be advocating for having many many many plugins for one
> tool.

I'm not sure if this is right conclusion. Advocating for keeping all
plugins well-defined is not the same as advocating for "many many"
plugins.

We don't have to go to either extremes. On one extreme, we can have
literally just one source plugin that can handle all possible tools
and configurations, and on the other hand we have the super
fragmentation of many many plugins. I think the sweet spot is
somewhere in the middle.

Thanks!
Chandan