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 <[email protected]>
> 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 <
> > [email protected]> 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
> >
> >
