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

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

> 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.



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: