Hi Ian!
On Sun, 2014-01-19 at 12:04:17 +0000, Ian Jackson wrote:
> Guillem Jover writes ("GR: Selecting the default init system for Debian"):
> > I think that forcing a decision through the TC at this time was very
> > premature and inappropriate, [...]
>
> Perhaps surprisingly, I am not entirely opposed to the idea of a GR
> for this question.
>
> My reasons are quite different to yours: to summarise, it seems to me
> that the init system decision involves political questions as well as
> technical ones.
Actually, no, part of my reasons include several of the ones you list,
as I tried to imply when writting “Such decisions, on issues that are
as much technical as strategic, political or of a subjective design
nature,”. I should probably have been more explicit (seems to be a
common fault of mine :/ ), but didn't want to go into specific details
for those, I guess that was a mistake. :)
For example with strategic, I was thinking about things like:
* Does the project want to align itself with an existing ecosystem
or distribution?
- Due to similarities and existing relationships with other
projects.
- Or due to perceived number of supporting distributions.
- Or due to perceived global userbase.
* Maybe even to try to tip the scale one way or another; either
to counterweight what might be perceived as having more support
by the rest of the community so that diversity is preserved, or
to try to standardize on a global one so that the others can
wane off, eventually?
For political, several of the ones you've listed, and of a subjective
design nature things like:
* Being more or less portable, allowing to use the full extent of a
system, or providing a common baseline for many systems creating
uniformity.
* Being more user extensible, or having no knobs and trying to have
only good defaults.
* Being tightly coupled or allowing for parts to be easily replaced.
* Shifting the complexity from system to the users (users here would
be daemons), or the other way around (implementation and interfaces
wise).
* Incremental evolution of existing systems or revolutionary new
systems.
* etc.
which in the end are all possible valid design philosophies, with
different tradeoffs, depending on the context, usage, expectations, etc.
Where reasonable people can have opposite opinions or preferences. A
really good characterization of what I mean could be the New Jersey vs
MIT schools of thought, as represented in the well known "The Rise of
Worse is Better" writup.
<http://dreamsongs.com/RiseOfWorseIsBetter.html>
> I do think that the proper process is for the TC to make a decision at
> this stage. The way I read the constitution and the context is that
> it is the TC's job. Evidently you disagree. But there are certainly
> things that some TC members are suggesting which would lead me myself
> to want to propose or sponsor a GR to overturn it.
If the TC was to continue making the decision, I'd want to run the GR
regardless of the outcome, even if I'd agree with it; althought as
I've mentioned before I find the 2:1 majority unfair.
> If we are going to have a GR, we need of course to have all of the
> sensible options on the ballot. I think your division of the key
> possibilities is sensible.
Thanks.
> However, I think your option (B) needs further reconsideration. I
> doubt the project will have the appetite for two GRs on this topic.
Well, I'd rather not be spending time in the current GR either, I'd
prefer to be doing something else instead, to be honest. But regarding
option B, I'd also very strongly prefer if no other GR would appear,
but I know that some people are eager to get a decision made and be
done with it (even if it would get postponed now), and will not want
to wait either, so that was more of a compromise than anything else.
> Most people are heartily sick of the subject already, probably.
> (Indeed I'm somewhat worried that people might want to punish the
> proposers and sponsors of a GR for prolonging such a tiresome
> dispute.)
(In a way I guess I accepted that burden when I offered myself as
a sacrificial token.)
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140119193601.gb4...@gaara.hadrons.org
