Patrick Ouellette <poue...@debian.org> writes: > On Thu, Nov 13, 2014 at 10:04:00AM -0800, Russ Allbery wrote:
>> In a sense, of course, this is true. However, what I'm trying to point >> out is that we have a fundamental governance question facing us here. >> What are we, as a project, going to do when we face a decision where >> the project is strongly divided and all sides consider the opposing >> decision to be a disaster? > What ever happened to letting the system evolve naturally? Rather than > force change on the users, let the quality and utility of the software > the user *wants* to run manage the timetable to change the foundational > elements of the system. This sounds great on the surface, but the general principle is hard to apply to the current situation for a couple of reasons. First, several of our upstreams have, from their perspective, already gone through this natural evolution process and have landed on a new set of software, which they are now requiring as a prerequisite. This is, in one sense, a normal thing for upstreams to do. It happens all the time with new shared libraries or new ABIs of existing shared libraries. However, this time, it's rather unusual, since it's unusually hard (although not completely impossible) to provide both the old and new mechanisms at the same time. It's not unheard of, though; we have retired old stacks before even though some users wanted to use them because they weren't supported upstream. I'm remembering the last GNOME and KDE major release transitions, for instance. (And, in the GNOME case, a team stepped up to maintain a fork, and as a result the previous version is being reintroduced in the archive under a different name.) Again, you can have many different opinions about these decisions, and I know people do, but the fact remains that the people who are making those decisions are independent citizens of the free software community with the right to make their own decisions. We don't get to tell them what to do; it would be extremely rude of us to do so, not to mention completely ineffective as we are not their bosses or owners. The alternative is what it always is in free software: if you don't like a project direction and can't convince the current maintainers that you're right, you either have to put up enough resources to maintain a fork or live with it. Second, our users are just as split as the developers are. Some users have already gone through the process you describe and are eager for the new software. Others are pretty leery or even actively opposed. If we can maintain both in parallel, this is not a problem, but it seems like everyone is dubious about the project's ability to maintain both, so one side is arguing for investing our time into supporting sysvinit rather than systemd, and the other side is arguing for investing our time into supporting systemd instead of sysvinit, both making essentially zero-sum tradeoff assumptions. The question of whether we can support both as first-class citizens is exactly one of the points of severe and apparently irreconcilable disagreement. In particular, one group feels like we should effectively force support for sysvinit as a prerequisite for having one's package included in Debian or remaining in Debian, even for packages where both upstream and Debian maintainer have already gone through the process you describe and are ready to move on to something else, and without a clear picture of who is going to be doing that work. And another group is uninterested in continuing to support sysvinit beyond the jessie release, because they don't believe the effort is warranted, are not interested in doing the work, and are dubious that the resources to do so will materialize. > Change from the status quo should be done when there is a compelling > reason to do so - and then with great care and consideration of the > consequences. And there are lots of people in Debian who have gone through this thought process and who believe that they are doing exactly this. And there are lots of other people who disagree. So, again, we return to the governance question. We're at loggerheads no matter how you cut it, including the way that you're trying to cut it. Do we wait for unanimity? Is that the right default decision? Unanimity in a project of 1,000 people is a long time. If we waited for unanimity, we'd still be shipping KDE 3. Would that have been the right decision? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wq6yeweo....@hope.eyrie.org
