Re: Being part of a community and behaving
Patrick Ouellette <pouelle@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: