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
