On Sat, Feb 01, 2014 at 12:34:19PM -0800, Russ Allbery wrote: > Steve Langasek <vor...@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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature