Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> Wouter Verhelst <[email protected]> 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 <[email protected]> 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.
