Hi Holger, (I'm only answering the first part of your mail -- I don't think that it's fair to alienate Ian and the supporters of Choice 1. I believe that they are all acting in good faith, pushing for what they think is best for Debian, and that their opinions should be respected.)
Here is how I see things.
There are four options on this GR. Choice 4 (which I support and helped
improve, at least IMHO) makes a clear statement about our
decision-making processes and the use of GRs.
The three other choices are different answers to the same set of
questions (see [0] for my personal detailed analysis of those, btw).
I don't think that any of those choices will beat Choice 4, but
Condorcet allows us to rank all options, and I think that the relative
ranking of choices 1, 2, 3 will still be a strong message sent by
Debian.
There are technical decisions in Debian that are easy to make, because
there's one optimal solution. That isn't the case here. There are valid
arguments to support both extremes, which are fairly well represented by
Choice 1 (=~ "we want to keep the ability to choose between init systems,
forever") and Choice 3 (=~ "let's let maintainers decide what is best for
their packages").
In Debian, we have a culture of seeking compromises in such situations,
and that's what Choice 2 is trying to do. It might not the optimal
compromise, but unfortunately, it is too late now to propose another
option. For my defense, I also (mostly) sticked to the wording used by
the TC back in February (see [1] for details and pointers).
The project seem to be heavily divided here. Choosing (1) or (3) would
make the losing camp very unhappy. Even if there's a 80/20 majority for
the winning option, can we afford to disappoint _that much_ 20% of our
contributors? I don't think so.
I would like to stress that the question being asked is not:
A) "what is your personal preference, as user or maintainer?"
But rather:
B) "What is best for Debian, what should Debian do, in your opinion as
a member of the Debian project?"
(A) is fairly easy to answer. (B) is much harder, and requires one to
consider the long-term consequences on Debian of each possible outcome,
for example.
I don't expect so many people to be super-happy if Choice 2 were to win
against Choices 1 and 3. But I hope that this is an outcome where a lot
of people would think "well, my own preference didn't win, but that
looks like an outcome I can accept."
Let me address your specific points now (reordering paragraphs of
your mail slightly):
> Choice 2 has two paragraphs I disagree with, rather strongly by now:
>
> ----begin part 1
> Package maintainers are strongly encouraged to merge any contributions
> for support of any init system, and to add that support themselves if
> they're willing and capable of doing so. In particular, package
> maintainers should put a high priority on merging changes to support
> any init system which is the default on one of Debian's non-Linux
> ports.
> ----end part 1
>
> So, about part 1 I disagree with telling maintainers what to do, that they
> should priorize supporting other init systems. IMO thats a.) completly up
> to the maintainer and b.) I think prioritizing security fixes and usability
> features and plain simple features is probably most always more beneficial
> for the average user. Or: whatever it is, but I hardly doubt it's wise to
> always prioritize support for whatever niche initsystem.
>
> So (IMNSHO anymore) this is stupid advice (with a "should" statement no less)
> harming our software and our users. I blame lost focus due to a distorted
> "discussion" for this.
There are lots of people who care about support for alternative init systems,
for various (often good) reasons. Should Debian completely ignore them? I don't
think so, but YMMV.
On "telling maintainers what to do", that's something we already do in
Debian. Caricaturing a bit, either your packages respect the Policy, or they
are out. One of the key things that Debian provides is standardization (in
packages installation, files layout, software features, etc). We define our own
standards, and apply them to all packages in Debian, even if it sometimes
requires us to disagree with upstreams. There are other distributions that make
different choices. For example, I'm told that Arch puts some emphasis on
following what upstreams decide. Should Debian change it policy to something
more like Arch? I don't think so, but YMMV.
(Also see Steve's mail[2] on the question of compelling maintainers to do work)
On "prioritizing support for init systems that are the default on non-Linux
ports over security fixes or usability features", this GR proposal does not say
anything about this. In some cases, it might make sense to prioritize support
for such init systems over security fixes, but the opposite is also true.
Maybe the wording is not optimal here, but you seem to be over-reading a bit.
> ----begin part 2
> There may be some loss of
> functionality under sysvinit if that loss is considered acceptable by
> the package maintainer and the package is still basically functional,
> but Debian's standard requirement to support smooth upgrades from
> wheezy to jessie still applies, even when the system is booted with
> sysvinit.
> ----end part 2
>
> And part 2 is too vague and broad at the same time, and also unrealistic given
> the circumstances (eg wanting to release in 2015). Again, I think these words
> aim and prioritize a rather unimportant (and unspecific) feature (and whats a
> smooth upgrade anyway? IMO a reboot is part of a smooth upgrade as only after
> a reboot I know the system can be rebooted safely...) and take away the
> opportunity to do the right thing instead.
Similarly to the specific paragraph about jessie in Choice 1, I don't
think that this statement about support for sysvinit in jessie (for
packages that supported sysvinit in wheezy) is going to add any
additional work during the freeze, because the current state of jessie
is fine in that regard. That whole paragraph prevents regressions by the
time we release, which is unlikely anyway thanks to the monitoring of
changes by the release team. I don't think it hurts, but it made more
sense in the original TC resolution, when there was a lot more time to
introduce regressions.
Now, as I partially announced my vote in [3], I'd like to say that I
changed my mind a bit. My vote is (currently):
Choice 4 > Choice 2 > Choice 1 > Choice 3 > FD
Details:
--------
I agree with the statement in Choice 4.
Amongst (1), (2), (3), I prefer (2), for the reasons given above.
I ranked all options above FD. I believe that this discussion is so
toxic that any decision is better than more discussion. I think that
we should move on.
(1) and (3) are both options I dislike quite a lot. I dislike (1)
because, instead of being a technical decision taken about the current
and near-future state of things, it is more a political decision that
strongly binds us to support several init systems for the long-term
future. I would have very much preferred a technical decision about
jessie and maybe jessie+1.
But actually, I dislike (3) even more, for the reasons detailed in the
subthread at [4]. I value standardization a lot. I think that this is
one of the main things that Debian provides. (3) is a big step towards
diminishing the importance of a common policy, by pushing important
technical decisions that affect standardization to the respective
maintainers. I think that all packages must support the default init
system (except in very specific cases), and we shouldn't allow
maintainers to decide otherwise because they think it's best for their
packages. (yeah, the wording in the amendment goes slightly further, but
I don't think it goes far enough -- also, we have existing procedures to
deal with cases where it makes sense to deviate from a common policy).
Lucas
[0] http://www.lucas-nussbaum.net/blog/?p=845
[1] https://lists.debian.org/debian-vote/2014/10/msg00043.html
[2] https://lists.debian.org/debian-project/2014/10/msg00078.html
[3] https://lists.debian.org/20141022150745.gb3...@xanadu.blop.info
[4] https://lists.debian.org/debian-vote/2014/10/msg00261.html
signature.asc
Description: Digital signature
