Re: [draft] Draft text on Init Systems GR
Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> Wouter Verhelst <wouter@debian.org> writes:
> > The problem with this is that it, essentially, promotes drive-by
> > patching: someone would like to use a program, but it doesn't come with
> > support for their init system.
> >
> > So they write that support, test it perfunctorily (enough for their use
> > case), and file a bug against the package. The maintainer is now
> > required to include it, because RC.
So far, this is my intent.
> > But let's assume there's a critical bug in the support they wrote.
> > Something that during the right phase of the moon could eat data.
> > That's RC, too.
But when this happens, my intent is what Russ writes:
> While I agree that Ian's wording doesn't say this explicitly, my
> assumption is that the maintainer could remove the sysvinit support if it
> is itself RC-buggy and the maintainer wasn't willing to fix it, by analogy
> to the case in the last paragraph above. Obviously, to be consistent with
> the rest of Ian's proposed wording, this should be done only as a last
> resort and after seeking help from the sysvinit community to fix the bug
> properly.
>
> That being said, the other point that Ian is making is that it's up to the
> sysvinit community to decide whether an RC bug that only affects the
> sysvinit community is actually RC. So in this case the release
> criticality of the bug would be decided by the same community which is on
> the hook to fix it, which seems fair.
I would be very open to wording change suggestions to address this
issue.
> It's not clear that this is technically feasible, so I'm not sure that it
> makes sense to mandate this solution in a GR.
Right.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: