Michael Gilbert <mgilb...@debian.org> writes: > On Mon, Dec 30, 2013 at 5:51 PM, Russ Allbery wrote:
>> I believe that we have enough information to make an informed choice >> already, and that the sides are fairly well-defined and hardened in >> their opinions. That means that this dispute falls under section 6.1.2 >> of the constitution: > I entirely concur that the social problem resides rightly within the > jurisdiction of the TC. With that said, however, it is worth > considering whether the role of the TC may be more effective if directed > at the root (the social), rather than the branches (the technical > choice), of the problem. The key, I think, is for the TC to provide a > reasonable path for those currently identifying with any of the hardened > camps to redirect their negative energy away from argument and toward > something more positive: technical work and actual code. Well, I think it's worth pointing out that my transition plan looks somewhat similar to your plan, as far as the jessie release. (Then it starts diverging.) Part of my goal in writing up that plan was, as you say, to try to provide a means for people who are committed to one system or the other to continue to work on what they're passionate about even if it's not chosen as the default init system. Whether they do so or not is up to them, of course, as it should be. However, I don't want to understate the amount of effort required to integrate with the init system across the distribution. I'm less pessimistic than Steve, but he's not wrong that the choice of a default init system will have sweeping consequences for what will work and what won't. This will particularly be the case if that init system supports capabilities beyond the sysvinit set. I do think it would be possible to maintain package compatibility with both systemd and upstart. That was something I was curious about and therefore explicitly tested as part of my evaluation, and was able to do so to my satisfaction. That said, I tackled a fairly simple daemon, and something like NFS support would require people with deep knowledge of each supported init system to maintain that support. I don't think it's a good idea to ask everyone to pursue all paths in parallel. I think Debian does a bit too much of that right now. We should pick a winner that we believe is technically superior and focus the mandatory, archive-wide effort on it. We should then *not get in the way* of people who also want to pursue alternative paths, but not assume that they will necessarily be successful, and not require that everyone get involved in that effort beyond the level of integrating patches that we currently expect for, say, the Hurd port. But, anyway, I don't think our positions are really that different. The main difference is that I think we should pick a default init system for jessie now, and you feel like we should do effectively an archive-wide bake-off and then go with whatever one achieves the best integration. I have to admit to a deep personal dislike of "contests" like that, since I find them stressful and demotivating and think they make the process of free software development less fun. I'd rather decide on our default and on the mandatory work now, so that everyone knows where they stand, and then let people make their own decisions about what they want to spend time on beyond the required minimum. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
