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.