Processed: block 726763 with 727708

[Steve Langasek]

On Sat, Feb 01, 2014 at 12:34:19PM -0800, Russ Allbery wrote:
> Steve Langasek <vorlon at debian.org> writes:

> > The above 'block' would be tantamount to an assertion that you have no
> > intention of accepting patches from maintainers of non-default init
> > systems to provide compatibility unless forced to do so by the TC;

> Wouldn't it be more reasonable to assume that the proper solution may
> depend on the TC decision and the corresponding fallout to package naming
> and structure, and hence it's reasonable to wait for the decision and
> subsequent fallout (particularly since that's close) rather than doing
> work now that may not apply to the final state of the world?

I don't think it's reasonable to leave testing and unstable users of our
default desktop environment without working suspend and resume for more than
a month (systemd-shim was accepted into unstable on Dec 28, and this was
mentioned on the bug) when a one-line change would fix the problem.  And
that fix would not cease to be correct if the TC decided that only systemd
should be supported for jessie, it would just cease to be important.  So
blocking on the TC decision (as opposed to either uploading the one-liner
change or, say, dashing off a message saying "I don't intend to work on this
but feel free to NMU") does suggest to me that

   However, where feasible, software should interoperate with
   all init systems; maintainers are encouraged to accept
   technically sound patches to enable interoperation, even if it
   results in degraded operation while running under the init system
   the patch enables interoperation with.

would be ignored, since otherwise I don't see anything in the options the TC
is considering, or in the broader discussion generally, which would impact
the maintainers' course of action here.

In other words: I think the technically correct thing here is obvious and
simple and invariant with respect to any decision the TC is going to make;
so the only way it makes sense to me that resolving the bug depends on the
TC decision is if the maintainers don't intend to do the correct, obvious,
simple thing unless the TC /requires/ them to do so.  And if we already have
examples of this before we've even changed the default init, then I don't
think we should pass any resolution that says we welcome multiple init
systems while at the same time leaving the door open for maintainers to
reject even such simple changes as this.

FWIW, I have a moderate preference for a stronger requirement that
maintainers be receptive to such patches, rather than dropping the language
saying that we welcome multiple init systems in Debian.  But that really is
just a moderate preference; the thing that bothers me here is declaring that
we welcome init systems while not actually providing the policy structure to
make that true in practice.  I think that's bad precisely because it
encourages developers to squander their energy trying to get patches landed
that aren't ever going to go anywhere.  We can decide that as a project we
want to support multiple init systems, or we can decide that we only want to
support one init system (per architecture, modulo upgrades) and let those
developers make an informed decision to spend their time on other things in
Debian; but let's not lead people on by saying one thing and doing another.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20140201/5ba9e989/attachment.sig>