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. 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? People caring about them could make software look for them in /usr/lib/init.d or such reducing various problems with removed-but-not-purged packages. Or would the people interested in shipping less configuration files have to implement this for non- standard init systems whose usage is explored as an experiment in Debian? Some people probably also want to continue to ship configuration files as Debian does now. Should we require this to be user-configurable? Who would be required to maintain maintainer scripts to support both configurations? The group wanting to keep the old configuration or the group wanting to support the new configuration? What if some people don't want this user-configurable (hmm, make user-configurability user- configurable?)? Or should be release team just decide all of this and everyone will accept this? I don't think that would work from past experience... Ansgar
