Re: Alternative proposal: focus on term limits rather than turnover
On Fri, Nov 21, 2014 at 08:54:31AM +0100, Raphael Hertzog wrote: > On Thu, 20 Nov 2014, Josh Triplett wrote: > > > I would suggest introducing a transitional clause that would state > > > something like: > > > > > > As a transitional measure, the terms of all current members that > > > exceed 4 years will only expire every 6 months, in order of > > > seniority. > > > > > > This would need some refining, but I hope you get the point. > > > > Seems reasonable, yes. I think that having the simplest possible > > functional expression of term limits seems like a feature, with a > > transitional measure *solely* to stage the turnover of the *current* TC > > over time (and thus set up for future staged term expiry as well). That > > makes more sense to me than baking in a "2 members" or "2-R members" > > rule going forward. > > Well, even if you bootstrap correctly, the TC members are free to resign > before their term and you can't ensure that the turnover rate will remain > constant. That's precisely the point of my proposal: I'm not attempting to ensure that the turnover rate will remain constant. As the subject line suggests, this proposal simply establishes a term limit, which guarantees a certain minimum rate of turnover. The turnover rate may exceed that minimum if people resign. (It might do so with the '2' proposal as well, as long as the committee size remains over the minimum.) I actually wonder if the various families of '2' proposals might work as a second clause added to a common term limit clause like this one. First state the term limits to establish a minimum rate of turnover, then define a maximum number of expirations applied per unit time. Common language on the term limits seems like a feature here, and I'd be happy to work towards that. > What happens if we have a GR that contradicts a TC decision and that half > the TC resigns because they no longer feel empowered to take more > decisions? You're back to your initial situation and we will have regular > large batches of changes. That case seems neither likely nor particularly problematic (from a term expiry point of view, I mean; from a project point of view it'd be a sign of something awful going on). We could choose to appoint only a couple of TC members at a time if we want to rate-limit things; we don't *have* to have a full 8 members on the committee at all times. Or we could appoint half the committee at once. I don't see it as terrible if we replace half the committee every 4-5 years; we'd still have significant continuity. > I think that I prefer a rule where we target a regular turnover of the > longest-serving members. Fair enough. However, I'd still like to see the simple term-limits-only proposal available as an option. - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141121173215.GB901@jtriplet-mobl1
Re: Alternative proposal: focus on term limits rather than turnover
Andrei POPESCU wrote: > On Jo, 20 nov 14, 13:23:04, Josh Triplett wrote: > > As a transitional measure, the terms of the current members of the Technical > > Committee shall instead expire every 6 months starting on 2015-01-01, in > > descending order of seniority; term limits then apply to them as normal. > > Since I've already messed up with the private/public replies I'll just > make one more post and then shut up. On the contrary, please keep providing valuable input. :) > IMVHO: > > 1. hard-coding a date (any date) might provide "interesting" side > effects, probably easier to just use the date of the adoption of the GR, > with some grace period (e.g. one month), to allow planing for the first > expiry. Fair enough. That seems fine to me. > 2. The above reads to me (as a non-native speaker) like it would apply > to *all* TC members, not only those with terms longer than imposed by > the (amended) Constitution. ...it reads that way to a native speaker too; good catch. :) > Slightly more complicated, needs review from a native speaker: > > As a transitional measure, the terms of any current members of the > Technical Committee that exceed the limit above at the time of > adoption of this General Resolution shall instead expire every 6 > months, starting one month after adoption of this General > Resolution, in descending order of seniority. That definitely fixes both issues. I'd simplify the language a bit, given that text in a GR by definition only takes effect when the GR passes: As a transitional measure, the terms of any members of the Technical Committee that already exceed the limit shall instead expire every 6 months in descending order of seniority, starting one month from now. - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141121163903.GA1566@jtriplet-mobl1
Re: Alternative proposal: focus on term limits rather than turnover
Anthony Towns wrote: > On Thu, Nov 20, 2014 at 11:25:10AM -0800, Josh Triplett wrote: > > This approach seems like it focuses too much on aggregate committee > > turnover, rather than just setting a term limit. > > Term limits rather than turnover was what I proposed originally; the > response to that was that people were concerned about it risking too > much churn. > > https://lists.debian.org/debian-project/2014/05/msg00054.html > https://lists.debian.org/debian-project/2014/05/msg00057.html > https://lists.debian.org/debian-project/2014/05/msg00059.html >From the second mail you linked: > I like Russ' approach here too, assign a random term start so we don't > suddenly have a large number of people being forced to resign and be > reappointed. Maybe just do it as a FIFO with a fixed distribution over > whatever we end up as the term limit? >From the third: > - in this kind of "reform" discussions I find generally useful to > distinguish two aspects: 1) the ideal model we want to have, 2) how to > migrate from the current model to that. Entangling the two aspects > usually make the status quo win over everything else, just because > migration is hard. > > For the migration in this specific case, random assigning start term > dates as suggested by Russ seems to be a brilliant idea. Distinguishing those two aspects is precisely what I'm trying to do here; the second proposal I sent incorporates a transition measure inspired by Andrei's suggestion, which is effectively the FIFO suggested above. - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141120213114.GA7172@jtriplet-mobl1
Re: Alternative proposal: focus on term limits rather than turnover
Andrei POPESCU wrote: > [private reply on purpose, since I'm not a DD] [Neither am I; replying publically since your reply was actually public.] > On Jo, 20 nov 14, 11:25:10, Josh Triplett wrote: > > > > """ > > No Developer may serve on the Technical Committee for more than 4 years > > out of any 6 year period. A Developer's term on the Technical Committee > > expires if they would exceed this limit. > > """ > > > > Exact numbers open for bikeshedding, but does the principle seem sound? > > It does to me, but given the current "age" of the TC members[1] the > practical effect would be that the terms of all TC members except Keith > Packard would expire as soon as the GR passes and assuming no member > ever retires the same will happen every 4 years (as per your suggest > numbers). > > [1] https://lists.debian.org/debian-vote/2014/11/msg00199.html (And https://lists.debian.org/debian-project/2014/05/msg00054.html in particular for the specific term lengths.) I'd forgotten that Colin was the only other member with less than a 4 year term (and he's leaving the TC); I'd thought there was one more. > I would suggest introducing a transitional clause that would state > something like: > > As a transitional measure, the terms of all current members that > exceed 4 years will only expire every 6 months, in order of > seniority. > > This would need some refining, but I hope you get the point. Seems reasonable, yes. I think that having the simplest possible functional expression of term limits seems like a feature, with a transitional measure *solely* to stage the turnover of the *current* TC over time (and thus set up for future staged term expiry as well). That makes more sense to me than baking in a "2 members" or "2-R members" rule going forward. Stefano Zacchiroli wrote: > On Thu, Nov 20, 2014 at 11:25:10AM -0800, Josh Triplett wrote: > > That also eliminates any issues of relative seniority, since we > > evaluate each member's term limit in isolation. It also eliminates > > any transitional issues, both because we don't link the expiry to any > > particular calendar date, and because by the time we pass this we'll > > have enough developers on the committee whose terms will *not* > > immediately expire that we won't have to appoint more in a rush. > > I wonder how you could be so sure about that. We just had three people leave the committee, and the TC put out a call for nominations; they plan to start evaluating nominated candidates on December 1st, so it seems fairly likely that we'll have at least three more new members roughly by the end of the year. I'd had the impression there were a couple more members with terms less than 4 years, but even a 4-person committee is enough to function and appoint more members. However, it seems easy enough to add a simple transition mechanism, and in particular (as stated above in reply to Andrei), it seems preferable to have a very simple term limit rule applied to *individual* members orthogonally rather than a rule applied to the committee as a whole. > But even if that is the case, replacing the whole (or mostly of) the > current CTTE with a freshly appointed one at the same time is very > likely to induce the problem that after another full term period (4 > years or whatever else the bikeshed says) from now you'll have another > large wave of batch replacements. Yes, that could happen anyhow, but is > much more likely to happen if you start enforcing a strict term limit > abruptly to all members, instead of doing so gradually. > > So, while your proposal is appealing in the abstract for its simplicity, > it is not really practical (in the current situation) without a > relatively complex transitional measure that make its initial > application gradual. > > > So, the complete diffstat of this proposal is +3-0, rather than +15-1. > > :) > > Yes, but to achieve a similar effect you'll have a much larger diff to > apply to the transitional measure, that you're trying to sweep under the > carpet :-) Not particularly. Incorporating a transitional measure like Andrei's suggestion: -8<- The Constitution is amended as follows: --- constitution.txt.orig 2014-11-20 13:14:40.018610438 -0800 +++ constitution.txt2014-11-20 13:15:23.714844659 -0800 @@ -301,6 +301,9 @@ appointment. 5. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee. +6. No Developer may serve on the Technical Committee for more than 4 + years out of any 6 year period. A Developer's term on th
Alternative proposal: focus on term limits rather than turnover
Stefano Zacchiroli wrote: > -5. If the Technical Committee and the Project Leader agree they may > +5. A Developer is not eligible to be (re)appointed to the Technical > + Committee if they have been a member within the previous 12 months. > +6. If the Technical Committee and the Project Leader agree they may > remove or replace an existing member of the Technical Committee. > +7. Term limit: > + 1. Membership of the Technical Committee is automatically > +reviewed on the 1st of January of each year. At this time, the > +terms of members who were appointed at least four and a half > +years (54 months) ago automatically expire. Expiry occurs in > +order of seniority, most senior members first, and is limited > +to at most 2 members per year. > + 2. A member of the Technical Committee is said to be more senior > +than another if they were appointed earlier, or were appointed > +at the same time and have been a member of the Debian Project > +longer. In the event that a member has been appointed more > +than once, only the most recent appointment is relevant. This approach seems like it focuses too much on aggregate committee turnover, rather than just setting a term limit. In particular, I don't see any obvious reason to limit expiry to 2 members per year (given that we have a process for appointing new members, and that we're about to do so), or to tie expiry to the calendar year (rather than the member's appointment), and I think the break before re-election could be incorporated into the term limit. What about something like this: """ No Developer may serve on the Technical Committee for more than 4 years out of any 6 year period. A Developer's term on the Technical Committee expires if they would exceed this limit. """ Exact numbers open for bikeshedding, but does the principle seem sound? We can leave it implicit that a developer whose term would immediately expire is not eligible for appointment, since doing so would be pointless. We don't need rules allowing a developer to stay on the committee despite their term expiring; we can easily predict such dates and plan on appointing new members by that time, just as we do for DPLs. That also eliminates any issues of relative seniority, since we evaluate each member's term limit in isolation. It also eliminates any transitional issues, both because we don't link the expiry to any particular calendar date, and because by the time we pass this we'll have enough developers on the committee whose terms will *not* immediately expire that we won't have to appoint more in a rush. So, the complete diffstat of this proposal is +3-0, rather than +15-1. :) - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141120192253.GA6120@jtriplet-mobl1
Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]
Sam Hartman wrote: > Matthew> Josh Triplett writes: > >> On Sun, Nov 09, 2014 at 12:22:07PM -0800, Josh Triplett wrote: > >> > What's the procedure for removing someone from the technical > >> committee? > >> > >> Someone pointed out to me privately that there's a much easier > >> way of handling this. See the "Maximum term for tech ctte > >> members" thread. Such a proposal would deal with this without > >> singling anyone out and without explicitly censuring any > >> particular actions, and would furthermore establish an ongoing > >> procedure that seems more broadly useful. > > Matthew> I'm not sure encouraging "if you hate Ian, vote for a > Matthew> maximum term for committee members" is very constructive. > > Hi Matthew, I feel that I at least haven't been heard very well when I > read the above and would like to be heard differently. > > I do not hate Ian. I do not think anything Josh has said implies that > Josh hates Ian. > I disagree with some of the actions Ian has chosen to take very > strongly. I believe that they tend to create a community that > discourages a form of compassionate, constructive discussion I value > strongly. > I value that form of discussion strongly enough that I believe it is > appropriate to take steps to exclude people who are not acting with > compassion and respect. Such steps can include talking to those people > and asking them to step back until they are ready, as well as more > formal procedures. > For me, nothing about this involves hate. > I can sometimes really understand a deep hurt that someone is feeling > that motivates them to act in a manner I disagree with. Often, that > understanding is sufficient that I can connect with them and find a > place where we can meet with compassion and respect. > Sometimes, the greatest understanding does not bridge that gap. > > Obviously, I cannot speak for Josh, but I hope I at least am heard > differently than you imply above. Speaking for myself: I agree completely with Sam's words here. This is not about hate. I simply care about the project and the people involved in it too much to keep accepting a continued pattern of harmful behavior against them. - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014023248.GA24450@thin
Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]
On Sun, Nov 09, 2014 at 12:22:07PM -0800, Josh Triplett wrote: > What's the procedure for removing someone from the technical committee? Someone pointed out to me privately that there's a much easier way of handling this. See the "Maximum term for tech ctte members" thread. Such a proposal would deal with this without singling anyone out and without explicitly censuring any particular actions, and would furthermore establish an ongoing procedure that seems more broadly useful. With that in mind, rather than encouraging the initiation of any kind of one-off process for this case, I would instead encourage anyone who feels strongly about this issue to participate in the drafting/sponsorship process of that GR, which at the moment needs one or more people to help work out exact wording, and which is likely suffering from current -vote/-ctte fatigue. [I'd like to thank the numerous developers who have responded either publically or privately. In particular, I'm glad that I was able to give a voice to concerns that many people did not feel comfortable raising themselves.] - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110100935.GG1085@thin
Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]
On Mon, Nov 10, 2014 at 11:01:46AM +0200, Aigars Mahinovs wrote: > On 10 November 2014 07:14, Josh Triplett wrote: > > For the sake of clarity, I'd like to point out that I didn't start this > > thread solely because of a single IRC log, but rather because of a > > pattern of behavior over the last year that shows no signs of changing. > > I do find it quite alarming that this discussion has now divulged into > a discussion of the behavior one of the initiators of the discussion > and has completely abandoned the actual issues. Regardless of who > started what and when, attacking personal credibility of your opponent > is not a winning argument. I am not in any way attacking personal credibility. I am expressing concern with observed actions, which seems entirely appropriate. > Even if person X feels that he is "at war", that alone does not make > his technical arguments invalid. Which is why I continue to engage with the technical arguments, separately. It does, however, call both his objectivity and his ability to effectively serve on a *dispute-resolution* body into question. > If you do not liek where Ian is coming from with his point of view - > do not argue with him. Argue with other people. Or, better yet, argue > with the facts. I've done that as well, for the last year. This has nothing to do with his point of view on specific technical topics; there are plenty of people on both sides of various topics (init systems and otherwise) who seem quite capable of doing an effective job on the TC. - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110094506.GF1085@thin
Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]
For the sake of clarity, I'd like to point out that I didn't start this
thread solely because of a single IRC log, but rather because of a
pattern of behavior over the last year that shows no signs of changing.
On Mon, Nov 10, 2014 at 01:48:42AM +0100, Bas Wijnen wrote:
> On Sun, Nov 09, 2014 at 12:22:07PM -0800, Josh Triplett wrote:
> > [CCed to a wider audience, but reply-to and mail-followup-to set to
> > avoid a prolonged cross-list thread.]
>
> > Sune Vuorela wrote:
> > > I have a hard time assuming good faith from people who are at war.
> >
> > Thank you for calling attention to that very disturbing IRC log. I'd
> > recommend reading the whole thing,
>
> I did, and I fail to see what is disturbing about it. I see a TC which
> has a good discussion over an emotional subject. And they succeed very
> well in keeping it civil almost all of the time.
>
> > 17:14:02 bdale: The GR is going to be another 3 weeks.
> > 17:14:09 We should decide on the automatic switch before then IMO
>
> What is disturbing about this? We were about to enter a freeze.
> Waiting 3 weeks before deciding on an issue which directly impacts the
> release doesn't sound like a good idea. How is that controversial?
Partly quoting for context, partly showing a general feel of charging
ahead, in this case without even respecting the GR process. We can
afford to wait for the project to decide how it wants to proceed; if
some change needs to happen to deal with this issue, I doubt we'd have
significant trouble getting a freeze exception for it.
> > 17:15:30 I don't think it's reasonable to say that we need a
> > tested alternative given how bad the situation is right now.
>
> If you think the situation right now is not so bad, of course you
> disagree with this. But from his point of view, that this situation is
> indeed very bad, there is nothing unreasonable about "let's do
> something, anything at all, to make sure this stops; problems we cause
> can be fixed".
First of all, bear in mind that I helped to revise the draft proposal to
flip the libpam-systemd dependencies around (see discussion in bug
746578), and now agree with the finished proposal to do so, so no,
that's not why I disagree with that.
I also advocated actually testing the result, which Christian Seiler
did. I proposed the change in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765101#38 to make
systemd-shim safer on systemd systems (by not shipping its own dbus
policy), which Steve Langasek agreed with and implemented in
systemd-shim 8-4, and someone else noted that cgmanager already avoids
running automatically on systemd systems.
I do indeed think that there's something extremely unreasonable about
charging ahead with an attempted solution without even testing the
result. ("We must do something. This is something. Therefore, we must
do it.")
> > 17:34:12 Diziet: I don't think that stating that we don't
> > want to swap on upgrades is something we can agree on
> > 17:34:25 Diziet: at least, not while the GR is happening
> > which seems to directly address this part of the question
> >
> > 17:34:28 dondelelcaro: That's not the question. The question is
> > whether it's something that would pass a TC vote.
> > 17:34:32 I'm done with consensus decisionmaking.
> > 17:35:34 That's not to say I'm not open to convincing. But
> > everything done by my opponents in this whole war has been done on a
> > majoritarian basis and I see no reason to limit myself to consensual acts.
> >
> > 17:36:48 Diziet: we can always go to majoritarian, but if we
> > can agree, so much the better.
> > 17:37:17 dondelelcaro: I and my allies have been being shat on by
> > the majoritarians since February. It's too late for that.
>
> Fair enough, this is a part where the level of civility is lower.
And this was the main set of items I wanted to call attention to from
the log, including the one that Sune originally pointed out.
> But
> Ian doesn't make an unreasonable point. If those who oppose him are
> forcing their side with an overruling vote, why should he refrain from
> doing the same? Consensus is great, but if we can't get there, we do
> want a decision. And majority is better than nothing.
No, majority is not necessarily better than nothing; "nothing" is often
a desirable result. You've forgotten to ask whether the TC should be
deciding something *at all*. The TC is an arbitration body of *last
resort*, not a body that should be frequently acting of its own volition
or that of one of its members.
Seeking consensus (whether successful or not) is a process that can hel
Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]
[Please CC me on replies.]
Don Armstrong wrote:
> On Sun, 09 Nov 2014, Josh Triplett wrote:
> > (After repetition of the exact wording of the "We aren't convinced"
> > wording that ended up passing, and people pointing out that it *will* be
> > interpreted as TC opposition to the switch, which sure enough it did...)
>
> The "we are currently skeptical" wording was not present in the passed
> resolution; it was amended in 7a000[1].
I stand corrected; thank you. However, I don't think that changes the
point. The resulting decision had effectively the same tone.
Linking to the resolution announcement for reference:
https://lists.debian.org/debian-devel-announce/2014/11/msg0.html
> That paragraph 4 of that decision could be interpreted as deciding the
> switching issue was only clear to me in retrospect, and was certainly
> not my intention (and I don't believe it reflects the intention of
> anyone else on the CTTE.)
I completely believe that it was not the intention of most of the people
voting for the resolution that passed. However, the combination of item
1 (explicitly narrowing the scope of the previous TC decision), item 4
(inviting proposals towards one specific approach), and item 5 ("After
the result of the General Resolution is known, we intend to formally
resolve the question", as though the TC *should* continue to take action
after the GR) comes across as both threatening and interminable, and
makes it fairly clear what action the TC wants to take.
Furthermore, the very top of the announcement in
https://lists.debian.org/debian-devel-announce/2014/11/msg0.html is
a lie of omission as well: "The technical committee was asked". As Joey
Hess put it in
https://lists.debian.org/debian-ctte/2014/11/msg00045.html:
> I am astounded that, in #762194, the technical committe has
>
> 1. Decided it should make a decision, when no disagreement
>between maintainers of affected packages is involved.
> 2. Ignored evidence of ongoing work.
>(specifically, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194#25)
> 3. Plowed ahead with a vote that decides a massively complicated
>issue with a grand total of 3 days of discussion.
>
> This is not a decision-making process that will yeild a high-quality
> distibution. Or one that I can be proud to be involved with. Or one
> that, frankly, gives me any confidence in the technical committee's
> current membership or indeed reason to continue to exist.
I agree almost completely with Joey's thoughts above, with one
exception. Personally, I still have plenty of confidence in almost all
of the technical committee's current membership, including those on
*both* sides of the current debate, with one very glaring exception.
I would also suggest that it's a bad idea to let a single member of an
arbitration body refer in a pile of issues, write up draft resolutions
for those issues, push for rapid discussion and votes on those issues,
and send out the resulting decisions. Those do not seem like signs of a
healthy process, and they certainly contribute to the impression of the
TC being used as a weapon.
- Josh Triplett
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141109220125.GA1457@thin
Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]
[CCed to a wider audience, but reply-to and mail-followup-to set to avoid a prolonged cross-list thread.] Sune Vuorela wrote: > I have a hard time assuming good faith from people who are at war. > > /Sune > > [17:35:34] > http://meetbot.debian.net/debian-ctte/2014/debian-ctte.2014-10-30-17.00.log.html Sune, Thank you for calling attention to that very disturbing IRC log. I'd recommend reading the whole thing, but I've called out a few particularly disturbing quotes below that make me quite done with assuming anything even remotely close to good faith anymore. (Note that "Diziet" is Ian's IRC nick.) 17:14:02 bdale: The GR is going to be another 3 weeks. 17:14:09 We should decide on the automatic switch before then IMO 17:15:30 I don't think it's reasonable to say that we need a tested alternative given how bad the situation is right now. (After repetition of the exact wording of the "We aren't convinced" wording that ended up passing, and people pointing out that it *will* be interpreted as TC opposition to the switch, which sure enough it did...) 17:34:12 Diziet: I don't think that stating that we don't want to swap on upgrades is something we can agree on 17:34:25 Diziet: at least, not while the GR is happening which seems to directly address this part of the question 17:34:28 dondelelcaro: That's not the question. The question is whether it's something that would pass a TC vote. 17:34:32 I'm done with consensus decisionmaking. 17:35:34 That's not to say I'm not open to convincing. But everything done by my opponents in this whole war has been done on a majoritarian basis and I see no reason to limit myself to consensual acts. 17:36:48 Diziet: we can always go to majoritarian, but if we can agree, so much the better. 17:37:17 dondelelcaro: I and my allies have been being shat on by the majoritarians since February. It's too late for that. (I'll also point out the pile of #action items Ian self-assigned, as well as the pile of times Ian has effectively self-referred items to the TC in the first place.) I've already felt from the more public portions of the TC discussions that Ian has been using the TC as a personal stick to hit people with. This makes it even more clear. See also Joey Hess's near-final mail at https://lists.debian.org/debian-ctte/2014/11/msg00045.html , pointing out the same issues. Calling this a war, being "done with consensus decisionmaking", "bitter rearguard battles" indeed... To put it bluntly: I don't believe this is even remotely acceptable behavior from a member of the TC (or a member of the project in general, but in the latter case someone has less potential to cause damage). Does anyone, in light of the above, feel even remotely comfortable having Ian continue to wield^Wserve on the technical committee? I don't care *how* you feel about init systems or any other issue; the above actions, tactics, and statements, and similarly consistent ones elsewhere are not even remotely acceptable on any side. The frothing-mad rampage and the battle-on-every-possible-front needs to end. I think it's safe to say that there's a substantial number of people hoping that the current GR will actually *settle* this question, with the project having spoken. We clearly have a pile of people who want to discuss and deal with the init system issue, many of whom are still capable of productive discussion and consensus-building. Many people are actively developing solutions to make the situation better. I've seen very impressive reasoning and careful judgement by various people in this and other issues. Russ Allbery comes to mind as the high standard we should expect from our TC members. And every other member of the TC, on *both* sides, seems quite reasoned and reasonable. So, at the risk of making things worse before they get better, since nobody else seems willing to explicitly say it: What's the procedure for removing someone from the technical committee? -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109202203.GA1700@thin
Re: `systemd --system` as a viable way out of the systemd debate?
Dimitri John Ledkov wrote: > On 4 November 2014 16:25, Gerrit Pape wrote: > > On Mon, Nov 03, 2014 at 04:37:45PM -0800, Josh Triplett wrote: > >> Russ Allbery wrote: > >> > Gerrit Pape writes: > >> > > On Sat, Nov 01, 2014 at 10:41:54PM +0100, Josselin Mouette wrote: > >> > > > Real problems? Apart from a couple of more reasonable people, I have > >> > > > yet to see systemd criticism in factual terms, rather than entirely > >> > > > made-up claims or vague accusations of destroying the Unix way of > >> > > > life. > >> > > > >> > > What is the reason that one can't easily run logind, or even better a > >> > > systemd process running logind and possibly other services, under the > >> > > runsv program from the runit init scheme, or through /etc/inittab? > >> > > >> > I believe it's that logind relies on the cgroups setup that's done by > >> > systemd, and that's what systemd-shim takes care of. > >> > >> Right. Specifically, logind uses the org.freedesktop.systemd1 DBus API > >> to configure "slices" and "scopes", which act like runtime-creatable and > >> runtime-configurable systemd units, including cgroup management. (Among > >> many other APIs.) > > > > To the best of my knowledge, neither cgroups nor d-bus require pid 1. > > > > Is this after all the root cause, a rather complex API implemented in > > pid 1 although it doesn't require any pid 1 capabilities? > > If so, I can understand why people might feel it's not "the Unix way of > > life." > > > > Is this the "coupling" the proposal talks about? > > I believe so, yes. > > And despite the complex implementation of the org.freedesktop.systemd1 > DBus APIs, it doesn't give full sub-cgroups access to the unprivileged > processes. > Whereas, cgmanager implementation provides a much simplier API, yet > allows unprivileged process to contain themselfs in sub-cgroups using > all available kernel cgroups stanzas. That's an intentional design choice in systemd: it provides a high-level API for process grouping and supervision, *not* a low-level interface to to the Linux kernel cgroup mechanism. Both potentially make sense depending on what you want. > I believe cgmanager is technically better cgroups implementation than > currently present in systemd upstream, and as an added benefit it's > implemented as a non-pid-1 daemon cgmanager is "better" at exposing the full details of cgroups; systemd is "better" at abstracting them. Also, handling cgroup management in a separate daemon would not work for systemd's purposes. PID 1 in systemd handles process grouping and supervision as a core part of its functionality, and uses cgroups to do so. However else you might feel about systemd's range of functionality, it'd be hard to argue that process supervision is not its primary job. It wouldn't make sense to launch and depend on a separate daemon for that; among other problems, how exactly would systemd manage cgmanager itself then? - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141104175036.GA6450@jtriplet-mobl1
Re: `systemd --system` as a viable way out of the systemd debate?
Russ Allbery wrote: > Gerrit Pape writes: > > What is the reason that one can't easily run logind, or even better a > > systemd process running logind and possibly other services, under the > > runsv program from the runit init scheme, or through /etc/inittab? > > I believe it's that logind relies on the cgroups setup that's done by > systemd, and that's what systemd-shim takes care of. Right. Specifically, logind uses the org.freedesktop.systemd1 DBus API to configure "slices" and "scopes", which act like runtime-creatable and runtime-configurable systemd units, including cgroup management. (Among many other APIs.) - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141104003742.GA28949@thin
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
[I agree wholeheartedly with Russ's points regarding systemd and logind. One tangential response to a different point:] Russ Allbery wrote: > There are a ton, but because Debian architectures encode choice of kernel, > they're represented in the archive as packages that are not available for > kFreeBSD or Hurd, or only available for kFreeBSD, or only available for > Hurd. That said, dependencies on specific kernel versions or features have no representation at all in Debian package metadata, which proves rather painful to deal with in packages that need specific kernel features enabled in order to function. - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141103024643.GA20402@thin
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
Aigars Mahinovs wrote: > Fedora actually is not that decisive, as far as I read here - > https://fedorahosted.org/fpc/ticket/243 That ticket turned down the suggested policy of "packages MUST NOT support sysvinit". That doesn't mean "packages MUST support sysvinit", or "packages MUST NOT depend on systemd". The Fedora policy: "Packages may also provide a SysV initscript file, but are not required to do so." - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141030140403.GA498@thin
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
Ian Jackson wrote:
> Marco d'Itri writes ("Re: Legitimate exercise of our constitutional
> decision-making processes [Was, Re: Tentative summary of the amendments]"):
> > ijack...@chiark.greenend.org.uk wrote:
> > >I don't want to be having this conversation again in a year's time,
> >
> > And still, I am ready to bet that we will...
>
> If my GR passes we will only have to have this conversation if those
> who are outvoted do not respect the project's collective decision.
>
> If my GR fails I expect a series of bitter rearguard battles over
> individual systemd dependencies.
In other words, if you win, everyone should just shut up and "respect
the project's collective decision", but if you lose, you intend to keep
fighting over every systemd feature you possibly can rather than
"respecting the project's collective decision"?
If you do not expect the vote on this GR and its collective amendments
to actually *end* this interminable issue and let people get back to
work, whichever outcome the project determines, what collective action
*would* have that effect, and could we get that on the ballot?
I tend to agree with Charles Plessy's simple statement that everything
is working just fine, but now I'm starting to wonder if Luca Falavigna's
proposal to *explicitly* say "go ahead and depend on an init system if
needed" would provide more closure on this issue.
- Josh Triplett
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141029221821.GA17894@jtriplet-mobl1
Re: `systemd --system` as a viable way out of the systemd debate?
mically launch a specific systemd unit. However, that would completely break the ability to use systemd dependencies, so I don't think that makes sense going forward. I'd be happy to help work on a coexistence solution like this, *if* it would actually end the interminable arguments over running systemd as PID 1. Any chance of it doing so? - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141028135809.GA5927@thin
Running systemd with PID != 1, coexisting with other inits
Matthias Urlichs wrote: > j...@joshtriplett.org: > > Personally, I'd actually love to see a port of systemd (a *complete* > > port of systemd) to be capable of running in system mode without being > > PID 1. > > Why would you need to port it? > You can do that today quite easily; just say "systemd --system". > > I have no idea what that does WRT cgroups management, and obviously it > won't be able to cleanly shut down the system, but AFAIK everything else > should work. Well, *that's* useful; thanks! I previously had the impression that systemd did not support this at all. If this *does* actually handle cgroup management properly, acts as a subreaper, and otherwise behaves as much like PID 1 as possible, then it ought to be possible to prepare a package that can coexist with sysvinit. That package could either install itself to /etc/inittab for supervision, or just supervise itself and launch from an early init script. (It would need to disable several of the default generators, most notably the one handling init.d scripts for obvious reasons, as well as many system units, but that seems doable.) The manpage does say "it is not supported booting and maintaining a full system with systemd running in --system mode, but PID not 1", but in this case, systemd wouldn't be doing the booting, just service supervision. Alternatively, I wonder how easily systemd could run as a single-service supervisor using --unit=, to run a single service or socket unit? Given an appropriate init script invoking systemd (probably via a wrapper to also handle the various init script arguments), that would allow writing an /etc/init.d/foo script that just runs a .service or .socket unit, supervised under a standalone instance of systemd. I don't know if multiple such invocations of systemd for different daemons could sanely coexist, though. I suspect a single system-wide instance would work better. Might also work to use --user for a systemwide instance, which would already disable most of the "system" functionality that would conflict with running another init. Using any of those approaches, it seems possible to build a daemon package that could then depend (directly or via a helper package) on systemd but *not* on systemd-sysv, and transparently work on whatever init system ran as PID 1. The first of the three approaches could also potentially support running logind and other such services. This seems like a sensible, sustainable, long-term solution for supporting multiple init systems as PID 1, while still allowing services to make use of systemd-specific functionality. (Much like services today could depend on runit.) Thoughts? - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141025155847.GA16223@thin
Re: Tentative summary of the amendments
On Sat, Oct 25, 2014 at 03:21:51PM +0200, Jonas Smedegaard wrote: > Quoting Josh Triplett (2014-10-25 11:52:28) > > Jonas Smedegaard wrote: > >> Quoting Josh Triplett (2014-10-24 16:27:27) > >>> Aigars Mahinovs wrote: > >>>> On 24 October 2014 13:33, Ansgar Burchardt > >>>> wrote: > >>>>> I don't like some software too, but am sometimes required to use > >>>>> it without an alternative. Can I demand that I can use packages > >>>>> without said software? Like demanding libraries having to provide > >>>>> language bindings for at least two languages so I don't have to > >>>>> use PHP[1]? :) > >>>> Init system is special because there can be only one active in the > >>>> system. If app1 depends on systemd (as PID 1) and app2 depends on > >>>> runit (as PID 1) then it becomes impossible to use both apps > >>>> (without changing init system and rebooting). Also IMHO init system > >>>> should be a user choice and not dictated by other, unrelated, > >>>> software. > >>> > >>> Kernels are special because there can be only one active in the > >>> system. If app1 depends on Linux and app2 depends on FreeBSD, then > >>> it becomes impossible to use both apps (without changing kernels and > >>> rebooting). > >> > >> Can you provide any concrete examples of that actually being an > >> issue? > > > > Yes, in both directions. > > > > For the more common "depends on Linux" case: portions of FUSE > > (partially addressed by a FUSE port for BSD, but not all filesystems > > work with that), ALSA (and indirectly anything using it for sound), > > BlueZ (Bluetooth support), more recent inotify-like interfaces, many > > networking and wireless tools, cell modem support, many filesystem > > tools, various hardware access libraries, some backup tools, some > > build tools, systemd and systemd-shim, and until not too long ago > > sysvinit. (That's only the software that *explicitly* only runs on > > Linux, as opposed to software which says "any" but doesn't build or > > run on FreeBSD, which I'd assume applies to a non-zero number of > > packages.) > > > > For the fairly rare (at least in Debian) "depends on FreeBSD" case, I > > only know one example off the top of my head: ZFS (since Linux only > > has the low-performance zfs-fuse). > > I meant examples not only of arch-constraints, but of arch-constraints > being an *issue*. Seems you provide only the former above. > > Existence of arch-constraints is analogous to existence of init systems > with different ABI. What we are talking about here is issues it causes > - whether those are mostly theoretical or actually occuring in Debian, > and whether they are treated as problems for package maintainers to deal > with (Policy "forcing maintainers to do "extra work" as some put it) or > not. Any missing functionality or packages on kernel or architecture A compared to B certainly is an issue for the people wanting to run A, and presumably the users, developers, and maintainers of A would like to see more packages and more functionality run on A. Policy certainly doesn't force package maintainers to do extra work in this case, because it places no hard requirements on architecture support. Porters write patches, and as I understand it the FreeBSD architecture maintainers do spend a significant amount of time making things work on FreeBSD and removing Linux-specific assumptions from code. FreeBSD developers upstream also work to provide kernel functionality to help support a broader range of software (e.g. linprocfs). Beyond that, I don't see what distinction you're drawing by about this being or not being an "issue". As mentioned below, the world certainly hasn't ended over it. Likewise, I don't know of any current "issues" caused by init-system-specific software that haven't already been fixed, and the world hasn't ended over that either. For architectures, kernels, *and* init systems, I personally agree with Charles' statement that "the procedures for decision making and conflict resolution are working adequately and thus a General Resolution is not required." Though for the purposes of curtailing further FUD and doomsaying, I'd personally rank Lucas's and Luca's statements higher. > > So, in a situation rather analogous to the init systems: Linux runs > > just about everything, FreeBSD runs most things but has
Re: Tentative summary of the amendments
cerns have concrete answers. > I still don't like the tightly integrated design, > but that in itself is just an irrelelvant opinion. There are people who still dislike Linux for not being a microkernel. :) And I wouldn't call your opinion *irrelevant*. It's a valid opinion, with some arguments in its favor; it happens to disagree with the direction and architecture of several widely used pieces of software, but that doesn't make your opinion *irrelevant*, just difficult to get support for. > >> Applications have never > >> been calling init system before. Try the same assumption with: bash, > >> Metacity, gnome-shell. "When you application is started, it might be > >> started by gnome-shell, in that case you may give gnome-shell an > >> indication about your startup animation, but you may be started by > >> something else, in that case you should still start, but it is fine > >> not to provide the correct startup animation." > > > > Talking about "startup animation" dismisses features and integration as > > trivial frivolities. Since you mentioned gnome-shell and metacity, > > let's talk about an analogous situation to the systemd case. Formerly, > > in GNOME 2, you could run a "panel applet" on top of gnome-panel, and > > run gnome-panel within any desktop environment and window manager you > > liked. Neither gnome-panel nor those applets exist in GNOME 3 > > Even though those were clearly understood to be plugins of the panel > and not actual applications, there was quite passionate discussion > about both porting them to Gnome 3 and about making a freedesktop.org > common ground specification. Basically system notification area came > out of that as far as I rememeber. I'm aware. The situation still stands, though, and the existence of ways to write more-portable, less-capable extensions (such as tray icons or notifications) does not negate the substantial ecosystem of gnome-shell-specific extensions. The same holds for init systems. Yet I don't see anyone clamoring to *prohibit* dependencies on specific desktop environments. Nor do I think an attempt to do so would be any more productive or effective. > > You're also implying that, out of a clear blue sky, the TC would declare > > a new default, as though they weren't asked specifically to decide an > > already contentious issue caused by a huge number of people *wanting* to > > support a new init system and being FUDded away from doing so. > > Actually I am suggesting that TC would make a trivial decision on what > is to be the *default* architecture, while other people would choose > to understand that this decision means that all other architectures no > longer matter. I think you've reversed cause and effect. There are a large number of people pushing to use systemd, and *because* of that systemd became the new default, as well as separately growing a set of software that depends on it. The TC's decision to make systemd the default is not the reason why people want to build software that uses systemd features. > > Finally, you're suggesting that code already exists that would be > > "cleaned up" and removed, and assuming that's the only reason to limit > > architecture (or init system) support. The common case here, however, > > would be *new* code to implement some new feature, depending on some new > > support provided by (for instance) a new service. > > That is exactly what I am suggesting - the reason for the clean up > would be to reduce maintenance burden and add new features by using > features easily available on the default architecture (both perfectly > fine reasons), but the side effect is loss of support for other > architectures (which is no longer considered to be important by the > upstream or maintainers). You're still conflating two separate items there, as though the software would just work on all init systems if only it didn't delete the pre-existing code to do so. As I said, the common case is either writing new software and not writing that extra code in the first place, or adding new functionality to existing software that depends on functionality or services provided by an init system. In the latter case, that functionality and those services are *not* trivial to duplicate. - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141025100526.GB1402@thin
Re: Tentative summary of the amendments
[Please CC me on replies; I'm not subscribed to -vote, so for mails not CCed to me, I end up responding via the archives and manually quoting via copy/paste.] Jonas Smedegaard wrote: > Quoting Josh Triplett (2014-10-24 16:27:27) > > Aigars Mahinovs wrote: > >> On 24 October 2014 13:33, Ansgar Burchardt wrote: > >>> I don't like some software too, but am sometimes required to use it > >>> without an alternative. Can I demand that I can use packages without > >>> said software? Like demanding libraries having to provide language > >>> bindings for at least two languages so I don't have to use PHP[1]? > >>> :) > >> Init system is special because there can be only one active in the > >> system. If app1 depends on systemd (as PID 1) and app2 depends on > >> runit (as PID 1) then it becomes impossible to use both apps (without > >> changing init system and rebooting). Also IMHO init system should be > >> a user choice and not dictated by other, unrelated, software. > > > > Kernels are special because there can be only one active in the > > system. If app1 depends on Linux and app2 depends on FreeBSD, then it > > becomes impossible to use both apps (without changing kernels and > > rebooting). > > Can you provide any concrete examples of that actually being an issue? Yes, in both directions. For the more common "depends on Linux" case: portions of FUSE (partially addressed by a FUSE port for BSD, but not all filesystems work with that), ALSA (and indirectly anything using it for sound), BlueZ (Bluetooth support), more recent inotify-like interfaces, many networking and wireless tools, cell modem support, many filesystem tools, various hardware access libraries, some backup tools, some build tools, systemd and systemd-shim, and until not too long ago sysvinit. (That's only the software that *explicitly* only runs on Linux, as opposed to software which says "any" but doesn't build or run on FreeBSD, which I'd assume applies to a non-zero number of packages.) For the fairly rare (at least in Debian) "depends on FreeBSD" case, I only know one example off the top of my head: ZFS (since Linux only has the low-performance zfs-fuse). So, in a situation rather analogous to the init systems: Linux runs just about everything, FreeBSD runs most things but has little that specifically depends on it. Which makes this a fairly small problem for Linux users, and a noticeable lack if you want to run FreeBSD. However, the FreeBSD folks have done an impressive job keeping up, and many packages have been willing to add FreeBSD support. (Processor architectures have a similar situation, most notably with packages that generate code and the packages that build-depend on those.) > Reason for this GR is concrete examples (thankfully believed solved by > now) of it actually being an issue regarding init systems. I have no reason to believe that the situation with init systems is drastically different than those for kernels or for architectures. In both cases, I think the right answer is for package maintainers to declare appropriate dependencies to reflect reality, for upstreams to consider carefully the tradeoffs of portability, and for port / init system supporters to continue writing and submitting patches or developing alternatives. Neither case justifies a GR or a policy "must". > > And yet we don't stop applications from declaring "Architecture: > > linux-any". And the world has not ended. People who maintain > > non-Linux kernels have a substantial amount of work to do, and I find > > it very impressive how much they've gotten working. Yet nobody has > > proposed a GR forcing support for kFreeBSD or the Hurd; the people > > working on them have simply *done the work*, and in some cases > > successfully convinced others to do the same. > > We do strongly discourage that, as codified in Debian Policy ยง5.6.8: > > > Specifying a list of architectures or architecture wildcards other > > than `any' is for the minority of cases where a program is not > > portable or is not useful on some architectures. Where possible, the > > program should be made portable instead. > > Notice the "should" near the end of above. Notice as well that it doesn't say "must". We've already had TC decisions that explicitly gave the equivalent of a "should"; this GR would effectively enforce a "must", making it RC to depend on an init system. The equivalent would be making it RC to not support all architectures. And while portability can potentially be a desirable feature, that doesn't make it RC to build architecture-specifi
Re: Tentative summary of the amendments
Aigars Mahinovs wrote: > On 24 October 2014 17:14, Josh Triplett wrote: > >> The key difference is that until this year all packages worked on all > >> init systems (as in you could start any service or application with > >> any init system as PID 1, even with "init=/bin/sh"). > > > > Until recently, it was a painful endeavor to be the upstream of a daemon > > package, because init scripts were not portable between Linux > > distributions; each distribution tended to have to write their own. > > systemd actually viewed that as a *problem*, and *fixed* it; it *is* > > fairly reasonable now to ship a .service or .socket or other unit file > > upstream and expect distributions to not need to change it. > > That is *not* what the discussion is about. It is *not* about init > scripts. Forget about init scripts. Imagine booting up a system with > "init=/bin/sh" - it should be possible to run a command to start your > service from there (without any init system at all). If you depend on > other services, then those should be startable with simple commands > too. If that is possible, then all is fine. "exec /lib/systemd/systemd". ;) More seriously, no, your expectations are no longer realistic or reasonable. It is already not possible *today* to run "simple commands" and end up with a working system; many services depend on other running services, and the thing gluing them together is an init system. You cannot, for instance, just run "foo-daemon" or even "/etc/init.d/foo-daemon start" for an arbitrary foo, not least of which because that won't enforce the starting of things foo depends on. In turn, those dependencies may include DBus services, or udev-managed devices and device events. You can't run DBus services without DBus (though systemd is actually working to fix that), and you can't generate udev events without udev. Without such mechanisms, software may well fail to launch or operate correctly. The world is more complex than your model, and has been for far longer than systemd has existed. Your init=/bin/sh system may well depend on an initramfs to successfully boot. You may not be able to type on your keyboard without running a daemon (e.g. for a Bluetooth keyboard). You might not even have a text console without running a daemon. Those daemons themselves may depend on other services. It's perfectly reasonable, for instance, for a daemon to expect to be run as a non-root user, and be handed a low-numbered socket that it could not itself open. It's not reasonable to require every daemon to reimplement that code itself, with all associated security requirements. It's also reasonable for you to reimplement that functionality in some other system, and convince upstreams to use your version instead. For instance, you might adapt a piece of software to work with inetd rather than a .socket file. > If systemd adds socket activation and you daemon uses it it is fine > for the start up of that daemon to use socket activation. If a user > is running another init system it is fine for socket activation not to > work, but a problem would be for your daemon to crash or hang on > startup because of this. Expect an increasing number of new upstream daemons to lack any code to daemonize themselves, or to start as root and drop privileges, when a perfectly reasonable and better-audited implementation already exists to launch the daemon as non-root with no forking. And that's two of several hundred features. You cannot expect all upstreams to *duplicate* functionality that already exists, nor to maintain such duplication indefinitely. > > In practice, demanding that packages work with all init systems, or even > > with *two* init systems, demands that they support the > > least-common-denominator of functionality provided by those init > > systems. That effectively makes any new feature added to an init system > > useless until duplicated. > > Yes - the demand is to make sure that the least-common-denominator > does actually minimally work. I appreciate that you actually acknowledge this rather than avoiding it, but nonetheless, no, arrogant demand refused; systemd, like the Linux kernel and many other pieces of software, provides useful functionality that other implementations do not have. Ask others nicely with convincing arguments and see if they'll do the work for you (many seem willing to), or do it yourself, or create other upstream software with different requirements that does not need systemd and package that software. > You may use the advanced features, if they are available, but can't > just assume that they will be. On the other hand it is fine to not > provide some functionality if the advanced init system features a
Re: Tentative summary of the amendments
king all those very useful features unavailable to users > of all other init systems. Like the upcoming wifi management changes - > those sound great, but there doesn't seem to be a reason why it > couldn't have been designed in such way that users of other init > systems could simply call some executable with some params and have > their wifi configured with those tools. I'm going to assume you're not particularly interested in hearing the Nth iteration of someone explaining reasons for such a design. > Being the default init system should not be the mandate to > break/rewrite everything else. In fact being the default init system > should bring great responsibility *not* to break stuff. First of all, software that does not work with systemd is not "broken"; it works just fine with its dependencies installed. If you want it to work with other software, that's a wishlist request, not a bug. In the more conventional sense of "break", systemd has in fact taken an extraordinary amount of care not to break stuff, frequently succeeding; I find it quite impressive how painless the transition has managed to be given the magnitude of the change. I would suggest directing your concerns either at upstreams to convince them to not use systemd functionality (good luck), or better yet into the development of alternatives that people want to use *more* than the versions in systemd. Absolutely nothing stops you. If you (and the entire set of people who agree with you) do not collectively have the time to keep up with the astonishingly rapid development pace of systemd, the right answer is *not* to hobble systemd or shout "wait up" at it, nor is it to hobble other software that wishes to use systemd until a duplicate implementation exists. - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141024142725.GA16732@thin
Re: Tentative summary of the amendments
On Fri, Oct 24, 2014 at 03:50:48PM +0300, Aigars Mahinovs wrote: > On 24 October 2014 15:40, Josh Triplett wrote: > > What makes the systemd case so drastically different that those who care > > about alternative init systems cannot follow the same procedure? > > The key difference is that until this year all packages worked on all > init systems (as in you could start any service or application with > any init system as PID 1, even with "init=/bin/sh"). Until recently, it was a painful endeavor to be the upstream of a daemon package, because init scripts were not portable between Linux distributions; each distribution tended to have to write their own. systemd actually viewed that as a *problem*, and *fixed* it; it *is* fairly reasonable now to ship a .service or .socket or other unit file upstream and expect distributions to not need to change it. And when functionality is missing, it's possible to get that functionality added; how long has it been since sysvinit added a new useful feature that daemons could use? Until recently, if you wanted your service to be restarted if it crashed, you had to use one of various separate packages to do so; sysvinit simply didn't *do* that. It *could* have; I'd love to know where we'd be a decade ago if sysvinit had had an /etc/inittab.d. A quick search turns up people asking for that in *1999*. There's a reason that systemd has had a meteoric adoption rate: it provides a huge number of features people not only want, but have wanted for years. In practice, demanding that packages work with all init systems, or even with *two* init systems, demands that they support the least-common-denominator of functionality provided by those init systems. That effectively makes any new feature added to an init system useless until duplicated. > The fact that the regression is introduced by an architectural > decision of systemd developers to tightly integrate system level > services into the init system (and not by a decision in Debian) causes > the feeling of loss of control. That's a very legitimate and accurate feeling. The people not doing the work don't have control. The people who are doing work on alternative implementations do have control of those implementations, and can make them as loosely coupled as they like. > Then asking others to implement > init-system-neutral versions of systemd-invented services just to keep > using software that used to work before is ... raising some hackles. "asking" for such alternative implementations isn't raising hackles; *demanding* is raising hackles. Even worse yet are the folks instead demanding that upstreams simply not use such services, or who insist that no possible use exists for such services. And in many cases, the systemd-invented services and features fill a gap for which no previously implementation existed, so "used to work before" is quite inaccurate. Not all features are optional; not every feature needs fallback code to cope with its lack. Doubly so if such fallback code does not already exist. - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141024141435.GA16989@thin
Re: Tentative summary of the amendments
On Fri, Oct 24, 2014 at 05:40:28AM -0700, Josh Triplett wrote: > Ansgar Burchardt wrote: My apologies, that should have been: > Aigars Mahinovs wrote: (The web archives on lists.debian.org have reply-to links, but those links don't include quoted mail text as the BTS links do; I copy-pasted the wrong name when constructing the attribution.) > > The root of the problem is coming from upstream not caring about > > alternative init systems. To take the logind case as an example - each > > of the dependencies from GDM to systemd make perfect sense in > > isolation. However, the end result (was) that GDM only worked with > > systemd almost by accident. No developer in that chain was compelled > > to run this under other init systems. > > We have not, historically, banned packages from introducing dependencies > on specific (FOSS) software they use, particularly in the absence of > patches implementing alternative dependencies. Imagine if we said "The > root of the problem is coming from upstream not caring about alternative > libc implementations.", and started complaining at packages that won't > build with newlib? Sure, many people have very legitimate reasons to > want to run some packages with a smaller libc implementation; however, > the burden remains firmly on them to make that work, and the project > cannot force maintainers of arbitrary packages to care about non-glibc. > > We have a substantial number of packages in Debian that depend > specifically on a Linux kernel, or even on specific architectures. > While there are people working to port those packages to alternative > kernels such as the Hurd and *BSD, I don't see anyone calling for a GR > to force packages to support alternative kernels; instead, I see the > people who care about running those kernels actually doing an impressive > amount of work to write patches. Similarly, even for packages that do > code generation (such as compiled programming languages), and thus only > support specific architectures, people have actually done the > substantial amount of work to add additional architecture support. > > What makes the systemd case so drastically different that those who care > about alternative init systems cannot follow the same procedure? > > > However these choices heavily impact our users who (for whatever > > reasons) want or need to use another init system. Such users are used > > to having to write an odd init script for some service - that is an > > acceptable extra work for using a non-default init system. However it > > is a much harder task to have to implement a new API introduced by > > systemd or creating something like systemd-shim. We should not be > > pushing such burdens to our users. That is too hard a punishment for > > using an alternative init system and also upstream (or maintainer) are > > far better positioned to implement some workaround to make the > > software work with alternative inits. > > Upstream and the maintainer don't necessarily *care*. A GR will not > make them care. As a user, if you want something that does not exist, > you file a wishlist bug and you hope to find someone willing to > implement it for you, or you work to convince people to care. > > (And to provide a bit of contrast here, several upstreams are making a > substantial effort to continue supporting alternate init systems even > when not doing so would be far easier and more fun. The near-complete > absence of any real examples in Debian of packages that currently > *don't* support sysvinit or that refuse to accept patches makes the > arguments surrounding this issue ring rather hollow.) > > - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141024124252.GA16760@thin
Re: Tentative summary of the amendments
Ansgar Burchardt wrote: > The root of the problem is coming from upstream not caring about > alternative init systems. To take the logind case as an example - each > of the dependencies from GDM to systemd make perfect sense in > isolation. However, the end result (was) that GDM only worked with > systemd almost by accident. No developer in that chain was compelled > to run this under other init systems. We have not, historically, banned packages from introducing dependencies on specific (FOSS) software they use, particularly in the absence of patches implementing alternative dependencies. Imagine if we said "The root of the problem is coming from upstream not caring about alternative libc implementations.", and started complaining at packages that won't build with newlib? Sure, many people have very legitimate reasons to want to run some packages with a smaller libc implementation; however, the burden remains firmly on them to make that work, and the project cannot force maintainers of arbitrary packages to care about non-glibc. We have a substantial number of packages in Debian that depend specifically on a Linux kernel, or even on specific architectures. While there are people working to port those packages to alternative kernels such as the Hurd and *BSD, I don't see anyone calling for a GR to force packages to support alternative kernels; instead, I see the people who care about running those kernels actually doing an impressive amount of work to write patches. Similarly, even for packages that do code generation (such as compiled programming languages), and thus only support specific architectures, people have actually done the substantial amount of work to add additional architecture support. What makes the systemd case so drastically different that those who care about alternative init systems cannot follow the same procedure? > However these choices heavily impact our users who (for whatever > reasons) want or need to use another init system. Such users are used > to having to write an odd init script for some service - that is an > acceptable extra work for using a non-default init system. However it > is a much harder task to have to implement a new API introduced by > systemd or creating something like systemd-shim. We should not be > pushing such burdens to our users. That is too hard a punishment for > using an alternative init system and also upstream (or maintainer) are > far better positioned to implement some workaround to make the > software work with alternative inits. Upstream and the maintainer don't necessarily *care*. A GR will not make them care. As a user, if you want something that does not exist, you file a wishlist bug and you hope to find someone willing to implement it for you, or you work to convince people to care. (And to provide a bit of contrast here, several upstreams are making a substantial effort to continue supporting alternate init systems even when not doing so would be far easier and more fun. The near-complete absence of any real examples in Debian of packages that currently *don't* support sysvinit or that refuse to accept patches makes the arguments surrounding this issue ring rather hollow.) - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141024124026.GA16686@thin
