[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [draft] Draft text on Init Systems GR

Wouter Verhelst writes ("Re: [draft] Draft text on Init Systems GR"):
> You can formally propose a GR today, and I recommend you do -- otherwise
> we end up discussing things before the discussion period, and then you
> need to sit and wait at least seven days during the *actual* discussion
> period for no good reason.

I see what you mean, but respectfully, I disagree.  There is no real
hurry about this - it is a long-term thing.  It is worth taking the
time to not just get the options right, but also keep everyone

In particular, if the DPL were to formally propose a GR, everyone who
wanted another option on the ballot would immediately be on the clock:
we would have to get our alternative either agreed with the DPL, or
seconded, within 7 days, if we wanted to be sure.  Given the febrile
atmosphere that some of these systemd discussions generate I think we
want at the very least the process to avoid any hint of anything that
feels threatening.

I also agree with the people who suggested that it would be best if
options were drafted by people who actually agree with them.  It is of
course helpful of the DPL to guide that process, but ultimately the
way the governance system is supposed to work is that people put
forward their _own_ options.

Whether it's helpful of the DPL to *start* this process is not so
clear to me.

But I do think we as a project as a whole have a problem here and it
is possible that another GR would help.  We have some outstanding
examples of cooperation and excellence, such as this one
Real work is being done and progress is being made.  But we also
have a very toxic atmosphere in some of our mail threads, and
unfortunate blocking behaviours.  (I won't give examples of those
since I don't want to turn the discussion into recriminations.)

I think what we are missing is a common understanding of the ground
rules of behaviour.  To my mind the basic principle of those ground
rules is that people should be allowed to work on what they want to,
within Debian.

It's no difference in principle whether it's a different init system,
or a different kernel, or a different libc, or a different desktop, or
a different package build system, or a different text editor.  People
they should be allowed to do their work.  If they need cooperation
from the rest of us, then provided the enthusiasts for whatever-it-is
are doing most of the work, then we should grant that cooperation.

That does not mean that we should support only the lowest common
denominator in our internal interfaces.  Indeed until fairly recently
Debian was leading in the design and deployment of good interfaces to
allow multiple different approaches to coexist.  This is stuff we are
really good at when we put our mind to it.

The political toxicity surrounding this one issue is preventing that.

So I think what we need is to define some practical rules for who gets
to do what, when, and what the consequences will be if certain work
does not get done.

I have a draft text which I will post shortly.


Reply to: