Re: Multi-package projects
Hi Ansgar,
On Fri, Oct 07, 2022 at 02:07:55PM +0200, Ansgar wrote:
> On Fri, 2022-10-07 at 13:37 +0200, Wouter Verhelst wrote:
> > - After the merits and problems of the proposed new projects are
> > discussed, the release team decides which projects are accepted for
> > the next release.
> > (I specifically do not mention what rules the release team should
> > follow in deciding which projects to accept -- I trust their
> > judgement)
>
> This sounds like you propose to create some sort of technical steering
> committee which probably should not be required to be identical with
> the release team.
Not really; we already have a technical committee, there is no need to
create another one.
> But as a practical example: some people have suggested packages not
> shipping configuration files in /etc (including, for example, init
> scripts in /etc/init.d). As far as I understand some people even say it
> is Debian's core mission to support such new configurations to give
> more freedom to users.
>
> How would this work and reduce conflicts with your proposal? Would it
> be okay for people driving this change to, for example, just drop
> /etc/init.d scripts?
[...]
My proposal would indeed not work if there are multiple projects that
want to make conflicting changes (i.e., one team that wants to remove
all files from /etc, and one team that wants to add init scripts where
necessary, which would by necessity be in /etc). I would expect the
release team in this proposal to make sure that no such conflicting
projects are accepted at the same time (or at least, for them to attempt
to do so).
On Fri, Oct 07, 2022 at 02:36:13PM +0200, Ansgar wrote:
> The proposal adds a few more bits reminding me of old concept of
> release goals (which Debian dropped),
Yes, I can see that. However, there are a few crucial differences.
Release goals were just "project wide goals that the release team thinks
are a good idea". If a vocal minority objects to the goal, then they can
veto it, at least for their own packages.
The idea here is to add ways to work around such an inactivity veto.
> but I'm not seeing how it would
> avoid the problems we had (or have) with systemd or usrmerge.
> It hides
> a lot of conflict behind this simple statement:
>
> | - After the merits and problems of the proposed new projects are
> | discussed, the release team decides which projects are accepted for
> | the next release.
> | (I specifically do not mention what rules the release team should
> | follow in deciding which projects to accept -- I trust their
> | judgement)
>
> and assuming everyone will then accept this decision.
It makes no such assumption; instead, it assumes that there will indeed
be people who oppose it, but that the project can still reach completion
even in the face of such opposition.
There are multiple ways in which Debian-wide projects fail:
- There will always be a group of developers who procrastinate on
implementing the required changes. This proposal makes it explicit
that the drivers of the project are expected to write the necessary
patches, and are allowed to NMU those patches given inaction by other
developers, so that procrastination cannot be the reason why the
necessary updates are not performed (unless it is procrastination on
the part of the project's drivers, but, well...).
- There are often some developers who prefer not to accept a given
patch, because they don't want to be responsible for maintaining the
offered code going forward. This proposal makes it explicit that the
drivers of the project remain responsible for the necessary code, even
after it has succeeded, and that it can be removed from packages with
immediate effect should the project no longer have the necessary man
power to keep up. This should (hopefully) mitigate that effect
somewhat.
- And yes, there is often (or perhaps I should say, "usually") a group
of people who think the whole idea is a bad idea to begin with, and
that Debian shouldn't implement this bad idea at all. These people
will refuse actively to accept the given patches, not for any of the
other two reasons I mentioned, but because they would rather that the
project fail. If the number of developers who feel this way is large
enough, then the project will likely fail to meet the release team's
standard of completeness when the project is evaluated. At this point,
the opposition will have "won", and the project-specific code can be
removed from the project. Alternatively, however (and what I consider
more likely), the vocal group of people who decided not to accept
these patches will turn out to be a small minority, the release team
will evaluate that the project has succeeded, and suddenly these
patches turn into RC bugs, meaning they will either be accepted
anyway, or the package in question will be removed from the archive --
either way, the proponents have "won", and the feature is available.
Perhaps my gut feeling that the third group of blockers are usually a
small (but vocal) minority is wrong, and this won't work at all. Perhaps
my gut feeling that the other two groups are much more commonly a reason
why a project isn't succeeding is also wrong, and then this also won't
work at all. But I think I'm not wrong, and therefore that it will work.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Reply to: