Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 11:24:31AM -0800, Russ Allbery wrote:
> 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.
We do tell users of Debian what to do - that's part of the problem right
now. We told the users they will switch init systems, and a large
portion (or at least a vocal portion) don't want to.
The current systemd / GR issue would not be happening if the project had
not said the default init system shall be <init system>. Had the project
said we have the following init systems available: <list of init systems>
and let the other package dependencies drive the user's selection then
users would fell there was a little more choice in the matter.
Right now, GNOME seems to be the primary driver for requiring systemd.
If you don't use a graphical environment, you don't need systemd but you
are forced to at least install it on a new build.
>
> 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.
>
If there are two opposing sides, then there are two maintainers willing to
maintain the packages. If there are not, the package without a maintainer
looses by default. I don't recall Debian every saying we will support package
<package> forever and ever.
>
> 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?
Waiting implies lack of movement - this is not what I was saying. I say
allow the natural evolution to play out. GNOME wants to require systemd
and someone packages systemd - great - allow it AS AN OPTION, NOT A REQUIREMENT
for all. Similarly with sysvinit - it has maintainers, allow it as an
option.
The issue we should be tackling is not which init system to force on
the users, but the higher level "what is the minimum functionality and
API a Debian init system MUST provide" to allow it to declare
Provides: init-system in its control file.
Pat
Reply to: