You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@buildstream.apache.org by Tristan Van Berkom <tr...@codethink.co.uk> on 2020/09/12 07:19:15 UTC
Ecosystem/extensions/plugins wrt ASF move [Was: make BuildStream
License Checker and official BuildStream project]
Hi all,
I fork()'ed the topic here as I think this is a separate and important
discussion to have...
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 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.
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.
* 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.
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.
* 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.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.
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
[0]: https://lists.apache.org/thread.html/r63a8ce551fdb2fc81f848e4ac0c59e3ec4a080682abe693ce5db82d3%40%3Cdev.buildstream.apache.org%3E
> Cheers,
>
> Sander
>
> On Fri, Sep 11, 2020 at 4:09 PM Benjamin Schubert <co...@benschubert.me>
> wrote:
>
> > Hey everyone,
> >
> > That seems like a good idea to me.
> >
> > I just have a meta question about such moves:
> >
> > What is the expectations we have for a project in order to move to the
> > BuildStream namespace? Who is responsible for maintaining it, making
> > releases where relevant, etc?
> >
> > Thanks!
> >
> > Ben
> >
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Monday, 7 September 2020 09:32, Tristan Van Berkom <
> > tristan.vanberkom@codethink.co.uk> wrote:
> >
> > > Hi Douglas,
> > >
> > > Thanks for bringing it to the list.
> > >
> > > For the readership, for avoidance of doubt: This particular license
> > > checker script is not the "whole story" around license related
> > > assertions and policy solutions for BuildStream projects, which has
> > > been under discussion here:
> > >
> > >
> > https://lists.apache.org/thread.html/re806060db181d176089108325d9c8564546f5e686eb96198ea9be458%40
> > <dev.buildstream.apache.org>
> > > As Douglas points out, this script in particular is basically a handy
> > > script which you can use for any BuildStream project to harvest license
> > > scanning results and view reports of such.
> > >
> > > On Fri, 2020-09-04 at 12:51 +0100, Douglas Winship wrote:
> > >
> > > > Hi everyone.
> > > > For a couple of weeks, we've been working on a Buildstream license
> > > > checker script. We're hoping that it can become a useful tool for the
> > > > BuildStream community, and we'd like to bring it under the BuildStream
> > > > umbrella by making it a project in the BuildStream GitLab group.
> > > > The tool is a python script that interacts with a BuildStream project
> > by
> > > > invoking BuildStream commands like 'bst show' and 'bst workspace open'
> > > > (using subprocess.call). The script checks out the source code of
> > > > BuildStream elements into temporary folders, and then uses a separate
> > > > piece of software called licensecheck to scan the files for license
> > > > information.
> > > > The final output is a list of licensecheck output files (one for each
> > > > element), plus human readable and machine readable summary files (html
> > > > and json, respectively). We're currently testing the tool by running it
> > > > in CI on a Freedesktop SDK branch. Sample outputs can be seen in the CI
> > > > job artifacts.
> > > > We'd appreciate feedback on the script itself, and on the idea of
> > making
> > > > it part of the BuildStream group.
> > >
> > > Normally we would add standalone python scripts like this to the
> > > contrib/ directory, like `bst-here` and others:
> > >
> > > https://gitlab.com/BuildStream/buildstream/tree/master/contrib
> > >
> > > However, I think that given the structure of your gitlab repo, it makes
> > > more sense to add this as a separate repo in the BuildStream group.
> > >
> > > Any other thoughts on this ?
> > >
> > > Cheers,
> > > -Tristan
> >
> >
Re: Ecosystem/extensions/plugins wrt ASF move [Was: make BuildStream
License Checker and official BuildStream project]
Posted by Douglas Winship <do...@codethink.co.uk>.
On 14/09/2020 22:09, Chandan Singh wrote:
> 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.
Other options are definitely possible, but I think the "shared
namespace" option is pretty hard to beat. It would make it unavoidably
clear that these extensions 'belong to' the BuildStream project, and it
leaves an utterly unambiguous cutoff between what is, and what isn't, an
endorsed project.
>> 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
>
+1
> 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.
>
I think that's part of the proposal? Someone definitely would be
responsible for maintaining it. It wouldn't be accepted as a BuildStream
project until someone had volunteered to be the official maintainer (but
that would most likely be the author of the extension, rather than
BuildStream 'taking on' responsibility for it).
> 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.
+1 If a maintainer leaves, they should put some time in to looking for a
successor, and at least tidy up after themselves before they go. We
should ask people to agree to this before we accept the project into the
BuildStream namespace.
>> * 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 think that if the extensions are useful and valued, then we probably
wouldn't drop the ball on them. Someone would probably be interested
enough to step in and pick up the responsibility. It's just that the
BuildStream development community shouldn't have to promise to do this
in advance.
If the BuildStream core developers end up obligated as a group to
maintain something, then that thing is effectively part of BuildStream
core. And these extensions shouldn't be that.
> If people cannot rely on our "blessed" projects to even exist, what
> would we be blessing them for?
This is an excellent question. I think that 'blessing' a script ought to
imply that the BuildStream maintainers think the script is:
1. "Good." (Useful, well written, probably not going to mess up anyone's
BuildStream project if used correctly) 2. "Compatible with the
BuildStream philosophy" (Does things in a sensible 'BuildStream-ish'
way) 3. "The right way to solve this problem" (So that people don't keep
reinventing the wheel, and can agree on a standard if a standard is
needed.)
In short, it would be a way of saying "we want people to use these
scripts" and "we definitely would like it if somebody maintained them",
without making any particular promise that the BuildStream Core
community is obligated to maintain them.
>> * 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.
Someone definitely needs to care about all of these things, and maintain the script. I think the point is that that obligation falls on whoever originally submitted the script and agreed to maintain it, not the core developers.
> <snip>
>
> Cheers,
> Chandan
>
<snip>
Cheers,
Douglas
Re: Ecosystem/extensions/plugins wrt ASF move [Was: make BuildStream
License Checker and official BuildStream project]
Posted by Douglas Winship <do...@codethink.co.uk>.
Hi Tristan
Good/Bad/Ugly sounds like a good idea for managing large sets of things,
and could apply very well to the plugins. When we've got a large group
of extensions/wrapper-scripts, it could make sense for them as well.
But at the moment, I think we've only got about 5 extensions? And that's
counting the ones from the contrib directory. So I'd rather hold off on
subdividing them and categorizing them for now. I'd rather make that
decision when we have more extensions, and a better idea how we feel
about them.
At this stage, I think we can easily get by if we just treat the
extensions as one big group of individial entities, and decide on a
case-by-case basis how much maintenance (if any) we want to commit to doing.
Douglas
On 18/09/2020 05:33, Tristan Van Berkom wrote:
> We've had many plugin discussions before, and one popular idea which
> might satisfy you would be to have a "plugins-good" / "plugins-bad"
> category system (like gstreamer has the good/bad/ugly packages).
>
> This would allow the core maintainers to make additional commitments to
> reviewing and maintaining a limited set of additional plugins (our
> little "cathedral"), while still having a larger ecosystem where the
> core maintainers do not make such commitments (our "bazaar").
>
> If we had such a separation, it would be good to consider additional
> pedantic criteria for "good" plugins, like:
>
> - cache key stability
> - YAML API stability
> - ...
>
> If we had such a separation, we might decide also to not make any `pip`
> packages or `pypi` releases of plugins outside of the "good" category
> (we would still want to make tarball releases for both categories of
> plugin package though, so any project can still access them with the
> "junction" plugin origin).
>
>
> Again, I need to emphasize that I don't feel strongly about the good /
> bad separation idea, I'm only throwing stuff at the wall to see what
> sticks :)
>
> Cheers,
> -Tristan
Re: Ecosystem/extensions/plugins wrt ASF move [Was: make
BuildStream License Checker and official BuildStream project]
Posted by Tristan Van Berkom <tr...@codethink.co.uk>.
Hi Chandan,
I've been meaning to reply to this for a while and have dropped the ball...
On Mon, 2020-09-14 at 22:09 +0100, Chandan Singh wrote:
> Hi all,
>
> I have been thinking about this topic in the background for a while as
> well, some thoughts inline.
[...]
> 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.
>
I should take the opportunity to point out that a lot of these types of
weekend hack projects are the kind of thing which remain useful for a
decade and hardly ever need any kind of maintenance.
If we have a well sealed core API which limits the plugins ability to
screw up or color outside of the lines; we can hope for this kind of
trend.
> 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.
Sure, that's what the straw man was for :)
> 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.
I don't think it's valuable to have a discussion about the short
lifespan of plugins from now until 2.0.
Right now I am breaking API and find myself fixing plugins in
bst-plugins-experimental, and the fdsdk plugins for the overnight tests
to keep passing.
That is clearly in our scope of duties while we are breaking these
APIs, but when discussing the "big picture" of plugins I think we need
to focus on the end result.
> 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.
This kind of system breakage is not particularly difficult to fix, at
least 99% of the time - what we're talking about here is fixing up some
python calls to be valid when supporting a new python3 version for
instance.
I think a more important question to ask here; is how do we expect
plugins to break when there is underlying system churn which causes a
malfunction ?
* If it will break loudly, i.e. a program will fail or there is
a python stack trace, then whomever is using the plugin can
notice the problem and fix it or at least file an issue.
* If it breaks silently, in such a way that for instance, the cache
key calculated by the plugin becomes random, but there is no
observable crash, then this is a bigger problem.
If there is a seldom used plugin which starts to break on systems 5 or
10 years from now due to some underlying system churns, I don't
personally care much, especially if it breaks loudly.
The way I see it: This is open / free software; if someone cares about
a given plugin, then that someone will come and fix it - in free
software we dont have "expectations" of maintainers to do things for us
for free, instead we have "contributions" from users who need to
scratch their itch - and we end up with better stuff in the end.
The above is really my opinion as a long time maintainer of FOSS
modules, I am only saying that realistically I would feel perfectly
comfortable with such an arrangement.
> > * 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.
The future I'm looking forward to is a future where:
- I can start using BuildStream 2 create a project
- I can regularly upgrade BuildStream 2 safely, that never breaks
anything
- I can still use the project I created in 10 years
I think that when a person wants to contribute a plugin, it is correct
to ask that person to "be around to fix problems in that plugin" for a
reasonable amount of time. I wouldn't want to define "reasonable" but
personally I feel like 3 to 6 months is the right amount of time where
we should expect people to fix the stuff they contributed but doesn't
work perfectly.
I think that after 2 or 4 years, people have moved on. The plugins
people contributed might have been "maintained" for a time when they
were contributed, but if people are using them 6 years later without
issue, there is no reason to remove them from the repository.
We've had many plugin discussions before, and one popular idea which
might satisfy you would be to have a "plugins-good" / "plugins-bad"
category system (like gstreamer has the good/bad/ugly packages).
This would allow the core maintainers to make additional commitments to
reviewing and maintaining a limited set of additional plugins (our
little "cathedral"), while still having a larger ecosystem where the
core maintainers do not make such commitments (our "bazaar").
If we had such a separation, it would be good to consider additional
pedantic criteria for "good" plugins, like:
- cache key stability
- YAML API stability
- ...
If we had such a separation, we might decide also to not make any `pip`
packages or `pypi` releases of plugins outside of the "good" category
(we would still want to make tarball releases for both categories of
plugin package though, so any project can still access them with the
"junction" plugin origin).
Again, I need to emphasize that I don't feel strongly about the good /
bad separation idea, I'm only throwing stuff at the wall to see what
sticks :)
Cheers,
-Tristan
Re: Ecosystem/extensions/plugins wrt ASF move [Was: make BuildStream
License Checker and official BuildStream project]
Posted by Chandan Singh <ch...@chandansingh.net>.
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
<tr...@codethink.co.uk> 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