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
