[I'm going to avoid responding to the points of this mail that Russ already did in his response, in favor of just agreeing entirely with that mail.]
Steve Langasek wrote: > On Sat, Feb 01, 2014 at 12:34:19PM -0800, Russ Allbery wrote: > > 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. As you already noted, your proposed solution had not been posted to the bug, and your statement that systemd-shim was not ready had been; thus, it doesn't seem particularly unreasonable for the maintainers to assume it wasn't yet a viable alternative. Furthermore, even the "one-line change" you're proposing needs some further discussion to evaluate it, and it has not yet had that discussion. Based on both of those points, I don't think it's at all reasonable to use 726763 as evidence that maintainers are not interested in supporting alternate init systems. I still think it quite likely that the majority of maintainers will take reasonable steps to incorporate proposed patches to support alternate init systems. > 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. [...] > 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. I think it's entirely possible that your proposal is not the "correct, obvious, simple thing" you see it as; it's not even the "correct, obvious, simple thing" for everyone who has been neck-deep in the entirety of this discussion, let alone for those who haven't been. I can also see several reasonable ways in which the appropriate change to this or any other involved package might differ based on the outcome of the TC decision. I don't think it's reasonable, given a very large solution space, to give preference to proposals based on their ability to keep their distance from 727708, rather than evalating all proposed solutions equally even if some might get embroiled in 727708. For that reason as well as just to limit complexity, I also think it's perfectly reasonable for a maintainer to wait for an outcome to 727708 before even enumerating the solution space. A brief, decidedly non-exhaustive look at the (potentially overlapping) solution space many packages could end up facing: - Add a dependency on "systemd-as-pid-1 (however we end up representing that) | systemd-shim (or similar substitute as applicable)". That would be appropriate if systemd becomes the default, or if the package provides degraded functionality under the alternative system was degraded. - Add a dependency in the reverse order, for the reverse of the above two reasons. - Add a "Recommends: systemd-as-pid-1". (Would work better if alternatives to systemd conflicted with it, so that you end up with systemd-as-pid-1 unless you have an alternative already installed or you intentionally ignore the recommends.) - Request a co-maintainer to keep an alternative tested and working. - Go up a level in the dependency stack and add an alternative dependency: "package-requiring-systemd | forked-package-maintained-by-someone-else", or an equivalent involving virtual packages, if a package requires invasive changes the maintainer doesn't wish to merge. - In the case of a daemon package, split out a foo-bin and foo package, allowing for a foo-otherinit package depending on foo-bin. Often convenient for other reasons, as well. - Change the maintainer to Debian QA Group (to further abuse Russ's metaphor, "shoot the hostage"). > 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. Given that 726763 does not actually qualify as evidence for your conclusion here, do you have any actual evidence that maintainers will behave as you fear, rather than that maintainers are capable of ongoing cooperative development? I'd also suggest in general that anyone looking to produce a non-trivial patch for a package might want to talk to the maintainer of that package to see what form of patch they would accept, which would be a far more effective means of avoiding wasted development effort. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140202005352.GA16529@leaf