[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

Hello Simon and others,

On Sun 29 Nov 2020 at 06:13PM GMT, Simon McVittie wrote:

> If we are unable to use particular system services (in this case NM) with
> a particular non-default init system without putting extra responsibility
> on the maintainers of those system services, then I think that's a
> limitation of that init system that its maintainers could usefully
> address, and addressing that limitation would certainly be within the
> scope of exploring alternatives to systemd.

This is a good way to understand the notion of "exploring alternatives
to" systemd.  Thank you for explaining it.

I have not yet seen an argument which convinced me that asking the NM
maintainer to keep the init script in the package would actually be
putting extra responsibility on that maintainer, and this concerns me.

Participants in the thread who have argued on that side of the
discussion seem to implicitly rely on the idea that a package maintainer
is responsible for applying an equally high level of quality assurance
to every file or feature in their package, as that which they would
apply to its most basic or flagship features.  For example, it's been
suggested that requiring the NM maintainer to keep the file in the
package would mean that the NM maintainer would need to keep a sysvinit
system around to test that the init script still works before they could
upload a new version of NM.  I don't see why there would be any such

Indeed, I don't think this is how we typically think of the
responsibilities of Debian package maintainers.  We want maintainers to
perform testing which is adequate to ensure that the core features of a
package won't regress if they upload a new version, but we do not take
maintainers to be responsible for testing every optional feature and we
accept that such things might be temporarily broken until someone other
than the maintainer can provide a patch.

In this case, I don't see how keeping the init script in the package
creates any expectations on the NM maintainer beyond applying patches to
the init script from those who have the relevant specialised knowledge.
A good analogy would be ports.  We do not expect maintainers to maintain
an environment to test their package on ports architectures before
uploading, but we do expect them to apply patches provided by porters
who discover regressions.  Why would our expectations be any greater in
this case?

Of course, if the script became seriously broken and was getting in the
way of a release or something like that, we would typically see it as
within the maintainer's prerogative to remove it.  Just as we would
accept a maintainer breaking compatibility with a port by reverting a
porter's patch if that was the only feasible way to meet a freeze
deadline, say.  But as has been pointed out, that's not the case we are
dealing with here.

I would like to see arguments that we would be imposing any extra
responsibility on the NM maintainer which do not rely on the idea that a
package maintainer is equally responsible for regressions anywhere in
their package, or, of course, an argument that I'm misunderstanding
what's being implicitly assumed.

The dependency issue is more challenging.

Sean Whitton

Attachment: signature.asc
Description: PGP signature

Reply to: