Hi all, I have been thinking about this topic in the background for a while as well, some thoughts inline.
On Sat, Sep 12, 2020 at 8:19 AM Tristan Van Berkom <[email protected]> wrote: > > Hi all, > > I fork()'ed the topic here as I think this is a separate and important > discussion to have... I agree, we should definitely have a meta discussion about adopting/hosting procedures for plugins, extensions etc. > On Fri, 2020-09-11 at 16:19 +0200, Sander Striker wrote: > > Hi, > > > > I just want to make sure we take our move to the ASF into account. So far > > I've been thinking that we are moving the core buildstream repository. And > > maybe a set of "core" plugins, but most of the other repositories are > > probably worth retiring/moving out. I don't think that adding what is > > essentially a project that could stand on its own into this namespace is > > necessarily the way to go. > > > > Thoughts? > > It turns out I have a lot of thoughts :) > > I'll try to categorize them here: > > > Hosting BuildStream plugins > --------------------------- > BuildStream core on it's own does not provide much features out of the > box; asides from some core related plugins (like junction, link, > filter, import, compose) we have agreed to keep only the `manual` > BuildElement. In terms of Sources, we've agreed to only keep `tar`. > > I could be fuzzy on the exact details but, the main point here is that > projects normally need a lot more than what is in core; and we have a > lot of good plugins to offer. > > * I do feel strongly that we should have a "blessed" place for all > of these plugins to live, as separate repositories but clearly > grouped together in a single place, where our documentation > provides clear links to these blessed plugins. I agree, on the condition that there is a blessing ceremony before we decide to host them. More on that later down below. > * I feel that it makes good sense for this location to be in the same > hosting space as core BuildStream. The messaging is more clear and > the ecosystem of plugins are more discoverable this way. While it is true that hosting all related projects under a single namespace would provide this messaging, I don't think it is the only way. With good use of documentation, GitHub/GitLab tags etc. I think this is a solvable problem even if such projects are hosted under different code namespaces. > If it turns out that we host the plugins in a completely separate > hosting for whatever reason, we should at least host these all > together as a logical group (perhaps keeping the BuildStream group > on gitlab.com for this purpose). > > > BuildStream extensions "are a thing", and hosting them > ------------------------------------------------------ > I believe we need to recognize and accept that BuildStream extensions > are a thing. > > The fact that the BuildStream CLI is API stable is our trump card for > rejecting feature creep which would inevitably turn our CLI into a > nightmarish monster, and allow use case specific special casing to seep > into our core like cancer. > > We now have a number of useful wrapper scripts which it makes sense to > recommend for various purposes, but we have not (yet) done very well on > making these discoverable or providing a consistent experience around > these. > > What I think, is that as long as we fail to provide a consistent > experience for extensions and wrapper scripts, we will continue to > struggle harder in our war against feature creep in the core; in the > absence of a clear story - people will continue to argue that the > BuildStream CLI "Should have this extra feature". > > > Extensions: Steps towards consistency > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > At the risk of this turning into a full proposal, what I think needs to > happen first is that we should nuke the "contrib/" directory into > oblivion. +1 > * The `bst-here` script and any other scripts currently living in > there, even if they are only stand-alone shell scripts, > should live in their own adjacent repositories, with their own > README files. > > * Similarly the license checking script will be its own repository. > > * Similarly the script which verifies artifact reproducibility (which > Jim MacArthur worked on years ago, and now is being rewritten by > Tomaz Canabrava[0]) should be in it's own stand alone repository > with it's own README. > > * I still think that the `collect_manifest` plugin problem needs to > be solved as an extension/wrapper script and not as a plugin, > essentially it is reporting information which should be exposed by > interfaces like `bst show` and similar. > > * BuildStream documentation needs to have a concise list of links to > these extensions (or wrapper scripts, however they are to be > called). > > On IRC a while back, Tomaz and I had a discussion about the > plausibility of building these extensions into the core, in such a way > that they could be installed separately but invoked through the `bst` > command line (in a similar way to how extensions to valgrind work), > just for the sake of discoverability for users... > > I'm not entirely convinced of this, but certainly the direction is a > good one and we need to cleanup our extension story. > > > Extensions: Hosting > ~~~~~~~~~~~~~~~~~~~ > I think that extensions need to be placed on equal footing with > plugins. > > Accessing extensions/wrapper scripts should be a similar experience as > accessing plugins; we should be able to go to the repository where it > is hosted, and find it's documentation in a similar way. > > We should also have a list of them maintained in the BuildStream > website somewhere. > > I think that in order to satisfy discoverability of features, we need > at the very least to have a dedicated go to location for "blessed" > things (where we can find both plugins and wrapper scripts). > > > Maintenance and guarantees of "blessed" plugins and extensions > -------------------------------------------------------------- > Ben raised some important questions about what criteria we have for > accepting a new extension, and what guarantees these will have moving > forward. > > I think that in this case we have a few main goals, and that they are > not all that hard to satisfy so long as we approach them with the right > mindset: > > * Clean UX regarding discoverability. > > There is a lot of valuable related work, we want to index it well > and provide a clean user experience for users to find the bits and > pieces which will make their lives easier. > > * Managing expectations. > > I think there is a general/natural worry, that if we publish plugins > and extensions as "blessed", that the core BuildStream developers > (whomever that might be at any given time) will be expected to do > work and keep them working. > > I don't want this to be the case and I would not support signaling > such expectations. Thanks for clarifying. I, for one, was concerned about having to be implicitly responsible for all potential plugins/extensions. Although I do think we need to have that discussion before deciding to host any more projects. I have seen lots of projects that start with good intentions, perhaps as a weekend hack, and then turn into abandonware due to lack of maintenance. I want to avoid this in our own BuildStream namespace. Historically, we haven't been that good in dealing with unmaintained projects either. For instance, I have been cleaning up the nosoftware group as a side job. I would like to not have to do more of that in future :) I understand that you posted a straw man proposal. But I do disagree on some fundamental points. I have commented on those further below. That aside, I do believe that this is an important discussion to have. And now is about time to have it. It is almost a bit late actually. > This point on it's own merits a whole discussion, as a straw man to > kick it off, I think I would be happy with the following: > > * Criteria for hosting an extension (be it a plugin or a wrapper > script) is that it has a maintainer. > > This can be a very low bar, given that these extensions hopefully > hardly ever need much maintenance. I disagree with the premise that these extensions will hardly ever require maintenance. This is certainly true today because we are breaking API left and right before BuildStream 2.0. If an extension is accepted today, it would at least require active maintenance until a stable BuildStream release, just to avoid breakages caused by BuildStream itself. More importantly, even if BuildStream was stable, we need to acknowledge that our dependencies will change, and distributions will move on. I will provide a recent example to illustrate this point. More than one such extension that we already have depends on Docker. In the latest stable release, docker's Python module made breaking changes that cause one of our builds to fail. If no one was responsible for actively maintaining such an extension, it would go unnoticed and cause disruption to people who rely on it. > * If an accepted plugin/extension stops working at some point and > the maintainer doesn't fix it, then it is up to the core BuildStream > maintainership to "archive" the module. I was also surprised to see that suggestion that we would just drop the ball completely on the project in this case. I would have thought about choosing to host a project as a "seal of approval" of sorts. If people cannot rely on our "blessed" projects to even exist, what would we be blessing them for. I would like to see that each blessed project has at least one maintainer (ideally more than one) who is willing to take responsibility for fixing bugs, major issues and breaking changes. And that they would find new maintainers in case that they can no longer maintain it. Perhaps by asking around on the mailing list. Finally, if they cannot still find a maintainer, they could archive it pro-actively, updating related documentation, updating on the list etc. This is definitely going to be some work. As such, I don't think it is such a low bar. But this would provide a great experience to anyone who might be using the extensions. Users would be able to rely on the fact that any project that is "blessed" is being actively maintained and wouldn't have critical issues. Quality over Quantity. > I.e. it is up to the BuildStream maintainership to maintain a list > of these plugins/extensions, but not the plugins/extensions > themselves. > > It is probable that BuildStream core maintainers will end up fixing > and maintaining plugins/extensions, but only because these happen > to be relevant to BuildStream core maintainers. > > * After BuildStream 2.0 is released, it is the primary responsibility > of BuildStream core maintainers to never, ever, break API. > > As such, we might expect to handle bug reports opened by extension > maintainers/users, if it ever accidentally happens that a plugin > or extension stops working because of a subtle BuildStream API > break. As I mentioned above, it's not just the BuildStream API we need to care about. Extensions also depend on Python API, host tools, runtime dependency constraints etc. They WILL break, it's only a question of time. For instance, one could argue that we should not bless plugins with external dependencies in the first place. In which case, we would need at least one policy to disallow them. In any case, my point is just that we need to agree on these policies > In this case it is of course our responsibility to fix things we > broke (hopefully this will hardly ever happen, or not at all). > > > Cheers, > -Tristan <snip> Cheers, Chandan
