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? An alternative to picking on one committee member would be to disband the current committee entirely, with an explicit rider stating that the action should not reflect on any one member in isolation. -- 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/20141110075510.gc27...@chew.redmars.org
Re: Plan B for kfreebsd
On Mon, Nov 10, 2014 at 06:05:25PM +1100, Andrew McGlashan wrote: > Debian kFreeBSD looks dead in the water and that won't change whilst so > many DDs are so pro systemd -- I think that systemd was the final nail > in the coffin. It won't change so long as people don't work on it. In a reply to a very similar-toned post of yours to debian-user, I pointed out that there were plenty of constructive ways that *you*, or anyone else, could contribute towards ensuring the next release of Debian was how you wanted it. In that case it was testing sysvinit support. If you truly cared about Debian/kFreeBSD, you wouldn't be trying to blame systemd for its shortcomings, you'd be rolling your sleeves up and fixing bugs. Please don't post any more to debian-vote. This list is meant to serve a particular purpose for people who are prepared to work on improving Debian. -- 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/20141110075054.ga27...@chew.redmars.org
Re: Plan B for kfreebsd
On 2014-11-10 7:05, Andrew McGlashan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Steven, On 10/11/2014 10:15 AM, Steven Chamberlain wrote: Jonathan Wiltshire wrote: We discussed kfreebsd at length, but are not satisfied that a release with Jessie will be of sufficient quality. We are dropping it as an official release architecture, Thank you for all your enthusiasm and support of kFreeBSD. [...] So sad that Debian is no longer going to be the universal Linux and that kFreeBSD is to suffer the consequences of the ... at best, controversial, systemd decision by the TC ... :( This really shouldn't need stating, but as people appear to be unable to separate issues and insist on dragging everything down to the same level - the Release Team decision on kFreeBSD was based on our opinion of the current status and supportability of that architecture, not a belief that Linux is somehow superior, nor any opinion on the merits of particular init systems, nor the phase of the moon. I'd appreciate an apology for having our motives impugned and this unfortunate situation used as yet another stick in an unrelated "dispute", but I won't be holding my breath. Unhappily, Adam -- 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/2746ccc44ef81d2d7fefd5310fd14...@mail.adsl.funky-badger.org
Re: Unsubscribing - let's use mailing list bans more frequently.
Hi, Charles Plessy: > I just suddenly wondered... How come Debian lists are trolled about systemd > and > not the lists on FreeDesktop.org ? Probably because instigating yet another endless discussion, and thereby preventing some systemd proponents from getting more useful work done, is more likely to succeed here … -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Plan B for kfreebsd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Steven, On 10/11/2014 10:15 AM, Steven Chamberlain wrote: > Jonathan Wiltshire wrote: >> We discussed kfreebsd at length, but are not satisfied that a >> release with Jessie will be of sufficient quality. We are dropping >> it as an official release architecture, Thank you for all your enthusiasm and support of kFreeBSD. However, it looks like Linux as we know it is at a crossroad -- it will be "Lennart Poettering Linux" or something else that something else looks like it will have to be FreeBSD direct now. Debian kFreeBSD looks dead in the water and that won't change whilst so many DDs are so pro systemd -- I think that systemd was the final nail in the coffin. So sad that Debian is no longer going to be the universal Linux and that kFreeBSD is to suffer the consequences of the ... at best, controversial, systemd decision by the TC ... :( A. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iF4EAREIAAYFAlRgY7MACgkQqBZry7fv4vu5sQEAujpbTZxDz7cSSk64z2QvOkqV mrkpYSBFHfZl+0pUZAAA/0uli8Ecr3QliKTKyg+Nxv9Bdo5G3o+MeHE/jIqKma/h =yQUp -END PGP SIGNATURE- -- 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/546063b5.5030...@affinityvision.com.au
Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]
> "Josh" == Josh Triplett writes: Josh> For the sake of clarity, I'd like to point out that I didn't start this Josh> thread solely because of a single IRC log, but rather because of a Josh> pattern of behavior over the last year that shows no signs of Josh> changing. Regarding the pattern: see the the CfVs[1][2][3] called in extreme anger, back in February. Those show a similar pattern. Concerns were expressed back then (including contacting the DPL and DAM), but apparently, nothing of substance changed since then. [1]: https://lists.debian.org/debian-ctte/2014/02/msg00344.html [2]: https://lists.debian.org/debian-ctte/2014/02/msg00353.html [3]: https://lists.debian.org/debian-ctte/2014/02/msg00355.html -- |8] signature.asc Description: PGP signature
Unsubscribing - let's use mailing list bans more frequently.
I just suddenly wondered... How come Debian lists are trolled about systemd and not the lists on FreeDesktop.org ? I do not have an answer but in the short term I am unsubscribing from debian-vote and maybe debian-devel later, until we as a project find a way to fix our communication channels, which are outrageously biased in favor of people who just talk the whole day, and against the people who would like to use these lists to achieve something useful. This said, if our Project agrees to be more liberal on mailing list bans, especially short-term ones (like one or two weeks), I volunteed to re-subscribe on debian-vote again do some of the work. PS: CC me if you need further input on my side. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan. -- 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/20141110062120.ga5...@falafel.plessy.net
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? Option 1: Agreement of DPL and an 1:1 majority in TC (6.2.5). Option 2: GR with a 2:1 majority to act with TC powers (4.1.4). Option 3: GR with an 1:1 majority to act with DAM powers (4.1.3) to expel the person from the project altogether. -- WBR, wRAR -- 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/20141110060322.ga6...@belkar.wrar.name
"Lennart Poettering Linux" -- some real eye openers here ... don't be blindsided!
Forwarding a message "as is" from another mailing list ... very relevant to Linux and the systemd dilemma. begin forward... http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html On Fri, 30.05.14 04:32, Michael Biebl (mbiebl at gmail.com) wrote: > > 2014-05-30 4:26 GMT+02:00 Greg KH : > > > You update systemd but you don't update the kernel? How does that make > > any sense? > > There might be very valid reasons why you need to stick with the old > kernel. As said, one example could be that the new one simply doesn't > boot. Requiring lock-step upgrades makes the system less > fault-tolerant. > So where possible this should be avoided. To make this clear, we expect that systemd and kernels are updated in lockstep. We explicitly do not support really old kernels with really new systemd. So far we had the focus to support up to 2y old kernels (which means 3.4 right now), but even that should be taken with a grain of salt, as we already made clear that soon after kdbus is merged into the kernel we'll probably make a hard requirement on it from the systemd side. I am tempted to say that we should merge the firmware loader removal patch at the same time as the kdbus requirement is made. As that would be a clean cut anyway... Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far. Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call. Lennart Poettering, Red Hat --- According to that logic, Linux is Linux+udev+kdbus+systemd .. In tone it is pure bullying. "I have taken udev and it will not work without systemd and I don't care about anything else". I don't think it fits in a GNU/Linux community project like Debian. It is not collaborative at all. It is good for a company like Red Hat to have "our ecosystem everywhere" but not for the rest. Lock-step is good for attackers. If I update X I better update Y and update Z too. oh, I don't know. Maybe don't update. And I do not need Z's functionality but I better do it all.. It is not good for embedded systems if the dependencies are many, become circular and hard to understand. The NSA will love it. Linux will work as long as you use it the way Poettering and Red Hat wants you to use it. Well, I have as much interest in it as using Windows or Mac OS X;-) BTW: People are mangling init(8) and sysV init in the discussion. You can run init and then comes inittab, rc.conf, /etc/rc to change between run levels and than /etc/init.d/*. You can change all that and it does not hurt a bit;-) Regards Peter ___ luv-talk mailing list luv-t...@luv.asn.au http://lists.luv.asn.au/listinfo/luv-talk -- 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/546053c0.5050...@affinityvision.com.au
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 help
discover additional solutions that may prove better than simply taking
the first available option that can pass a majority vote. (Also worth
pointing out that there's a reason we don't use simple-majority as our
voting system. Our voting system in fact explicitly favors options that
produce broader consensus; it only devolves to simple majority when we
have only two opt
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: > [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? > 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". > 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. 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. > (I'll also point out the pile of #action items Ian self-assigned, What's wrong with that? Would you rather see him say "This needs to be done; someone else do it please"? If the others would disagree that it needs to be done, they would speak up. That seems to be exactly the reason he's publishing his intent to do this: to make sure there is consensus that it is something that needs to be done. > as well as the pile of times Ian has effectively self-referred items > to the TC in the first place.) He is a DD, you know? Why would he not be allowed to refer items to the TC? He could of course ask a friend to do it for him, but that would just be useless work. He has every right to refer items to the TC. > 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. I don't share that view at all. Ian feels strongly about the issues, and gets carried away at times. IMO, that is a feature, not a bug, for a TC member. > Calling this a war, Have you followed the discussion? This _is_ a war. And not just from Ian's side: the pro-systemd amendment in the current vote seems to say "we demand that you trust everything we do, and we don't trust what you do". When I first read it my reaction was "Woah! That's a declaration of war!" How anyone could think it would be a good idea to include that in the amendment was beyond me. But I think I understand it now. Because it already is a war; no need to declare it. These people, just like Ian, feel strongly about this. And that is in fact a positive thing, just like I think it is positive that Ian feels so strongly about it. It means that they aren't cold-heartedly sabotaging the system as ordered by their corporate overlords. That may seem obvious, but it hasn't always been clear. ;-) > 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). Which part is the problem? That he has a strong opinion? That he wants to speed this up and get to a decision, even without consensus? That he states facts? The only problematic part I see is that he gets carried away at times. That's a very minor issue, and I forgive him, as long as he isn't insulting people. In fact, I not only forgive him; I applaud him for it; it shows that he cares. > Does a
Re: Maximum term for tech ctte members
Le Sun, Nov 09, 2014 at 03:08:39PM +0100, Lucas Nussbaum a écrit : > > When replacing two members at a time, it might be a bit difficult to > take that desirable balance into consideration. For example, if there are > three candidates A - B - C in the shortlist, and A and B are basically > clones in terms of profile, it would make sense to choose (A OR B) AND > C. If the final decision is made via a vote, it could require to vote on > pairs of candidates. Hi Lucas, actually, replacing two members at the time would give a good opportunity that at least one of the members is not a western male that is is fully fluent English speaker. While there is nothing wrong with that profile by itself, we are missing something when all the members have this profile. It is good to value technical excellence, but the work to be done in structures like the technical comittee needs other skills as well. I think that somebody who has a good capacity of synthesis, seeking advice, and understanding other people's points of view would also be very qualified. Said differently, I think that we give too much importance on who the TC members are, as compared as what they can do. Let's remember that the TC has a long backlog, so somebody who can learn and has time to do so will be more efficient than somebody who knows but has no free time. Rotating people by pairs would be a good opportunity to make it easier to introduce diversity in the technical comittee. (I am not suggesting to change the current proposal to ensure more rotations by pairs). Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20141110001313.gc13...@falafel.plessy.net
Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]
* Don Armstrong (d...@debian.org) [141109 22:22]: > 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]. > > 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 fully agree to that statement (and to the rest of your mail). > Indeed, paragraph 4 of that decision is actually a reflection of my > personal reluctance to decide this issue in the CTTE without a very > specific technical proposal and thorough testing. Also, we shouldn't decide on things not ready, and so in case someone would like the ctte to overrule here, there is just no ground currently. So anyone wanting a specific decision from the ctte (like "the default shouldn't switch on dist-upgrade", "the default should switch on dist-upgrade", or whatever else) needs to show before the decision that this is reasonable possible, what are the downsides of the decision and also why the ctte needs to decide (especially as the ctte only decides as last-resort). Details see paragraph 4, for any decision. So we could clone paragraph 4 to an 4a, 4b etc for any of other cases people would like us to decide here. In hindsight it might have been better to not decide yet but to suspend that topic until we had that plan but it's easier to say so afterwards. In theory our decision is nothing else, but some people interpret it different which makes me quite sad. Andi -- 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/20141109221450.gb...@mails.so.argh.org
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]
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]. 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.) Indeed, paragraph 4 of that decision is actually a reflection of my personal reluctance to decide this issue in the CTTE without a very specific technical proposal and thorough testing. Especially considering that we would be overriding the transition plan announced in https://lists.debian.org/debian-devel/2014/07/msg00611.html at a very late date. See https://lists.debian.org/msgid-search/20141107211930.gm29...@teltox.donarmstrong.com for my specific response to this issue when it was raised. 1: http://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/commit/?id=7a0009d350d57b89aa848f4d66a0b40959893373 -- Don Armstrong http://www.donarmstrong.com If you have the slightest bit of intellectual integrity you cannot support the government. -- anonymous -- 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/20141109212136.gg29...@teltox.donarmstrong.com
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: Maximum term for tech ctte members
> "Lucas" == Lucas Nussbaum writes: Lucas> Hi, Lucas> On 21/10/14 at 17:41 +, Anthony Towns wrote: >> Membership of the Technical Committee is automatically reviewed >> on the 1st of January of each year. At this time, the terms of >> the N most senior members automatically expire provided they were >> appointed at least 4.5 years ago. N is defined as 2-R (if R < 2) >> or 0 (if R >= 2). R is the number of former members of the >> Technical Committee who have resigned, or been removed or >> replaced within the previous twelve months. Lucas> Something just occurred to me. Lucas> Given the wide range of questions brought to the TC, it makes Lucas> sense to have some diversity in the TC in order to have Lucas> expertise at hand covering all the possible questions. Some Lucas> members might be more familiar with say, porting issues, Lucas> packages inter-dependencies issues, low-level stuff, desktop Lucas> environments or might have a tendancy to approach problems Lucas> with a sysadmin POV, or with a developer POV. Lucas> When replacing two members at a time, it might be a bit Lucas> difficult to take that desirable balance into Lucas> consideration. For example, if there are three candidates A - Lucas> B - C in the shortlist, and A and B are basically clones in Lucas> terms of profile, it would make sense to choose (A OR B) AND Lucas> C. If the final decision is made via a vote, it could require Lucas> to vote on pairs of candidates. I've been on the IETF nomcom which does have exactly this problem. They do vote on slates of candidates with ranked ballots similar to Debian's ballots. "works fine." More generally, this procedure does not remove flexibility from how TC members are appointed. That process can be serialized say with two quick votes, or with slates, or however the DPL and TC like. Depending on the specifics it may be the case that one member is technically appointed before another, although I'm sure any good rules lawyer can give you 5-6 ways around that too. I agree with your problem, but don't believe this proposal needs changes to give the DPL and TC adequate mechanisms to address it. -- 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/014995e67c41-c5bfde03-ca99-411a-9ced-e66d2055de0d-000...@email.amazonses.com
Something Constructive out of Disgust and Rearguard Battles
> "Holger" == Holger Levsen writes:
Holger> I'm also utterly disgusted that this GR was proposed by Ian,
Holger> someone who perceives himself as loser of the tech-ctte
Holger> decision (instead of accepting a group decission of a group
Holger> which he is part of) and thus deciced to beat Debian into
Holger> shape via this GR - and who has already announced that he
Holger> will not keep quiet if he looses the GR and only will be
Holger> quiet if he wins. (I'm happy to provide the message-id for
Holger> this... but I'm sure people do rememeber.)
Holger> This makes me quite very sad. From a responsible and
Holger> reasonable tech-ctte member I would have expected (and I
Holger> still expect!) to see the bias and act accordingly, as in:
Holger> step back.
Holger> cheers, Holger
Hi.
I think my position in this has been made very clear by my mail to
debian-project: my hope is that we can all work together with compassion
and respect when this is done.
I appreciate your cander in sharing your disgust when you read Ian's
message.
Let me see if I got what you are feeling correctly. You're feeling
disgust because you're hoping that the project's decision making
processes will be respected and you're hoping that people will act in
good faith.
Have I got that right?
I'd like to share Ian's text on this:
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...
Ian>If my GR passes we will only have to have this conversation if those
Ian>who are outvoted do not respect the project's collective decision.
Ian>If my GR fails I expect a series of bitter rearguard battles over
Ian>individual systemd dependencies.
I cannot think of a time when I've felt more disappointed in my Debian
work than when I read that text above for the first time.
However, there is a grain of something positive in that text.
Ian believes that his resolution makes a fairly strong statement against
coupling replacements to traditional unix facilities with an init
system.
None of the other options really answer this question at all. Even
choice 3, maintainers may do whatever they like, doesn't overrule the
policy process for anything other than init system choice. Policy could
still cover how Debian handles Cron (it does today); it could cover
logging (it sort of does today), it could cover time sync, it could even
cover logind. All that would be left up to the normal process on
debian-policy. That's even more true of choice 2, 4 and of course
choice 5.
If Ian had said that if his resolution fails, we're going to have some
complex policy discussions on each systemd feature, I would have agreed
with him.
That's how we handle technical policy: we have complex discussions about
it.
Even Russ, who I think is generally viewed as fairly pro-systemd has
said that he doesn't favor replacing cron, and favors fairly strongly
keeping with syslog in most cases. Russ believes we can get a quick
consensus on those points. I'm less rue, but I think we'd all agree
that choice 2-5 imply we'll be having individual discussions of all
those points on the policy list and some may rise to the TC.
The phrase that brings that sharp sense of disappointment is the phrase
"bitter rearguard battles".
Ian doesn't say that he will make the battles bitter. he may just be
expressing his frustration and disappointment and lack of confidence
that those discussions will rise to the highest quality ever seen on
debian-policy.
However, I think it is easy to see why we might be skeptical that
someone who phrases things that way would rise to the challenge of doing
everything he could to maintain the quality of the technical
discussion.
No matter.
So, Holger, everyone who feels something strong when they read Ian's
words... I challenge you, I challenge myself to turn that strong
emotion into something positive.
I hope we are committed to actually having discussions that need having
even if they are a bit challenging. I hope we're committed to having
them with respect that there are valid viewpoints on both sides. Not
telling maintainers what to do balanced against consistency of the
system overall is one of the most basic challenges.
Let's commit to holding those discussions to respect and understanding
and not allowing them to fall to the levvel of "bitter rearguard." We
welcome input. If people let their emotions get ahead oftheir
respectful participation, we do
the following:
1) Offer to spend time off-list understanding their feelings and trying
to find constructive ways of bringing their needs into the discussion
2) Offfer to welcome the person back to the discussion when they are
able to participate with respect if the discussion is still
Re: REISSUED CfV: General Resolution: Init system coupling
On 2014-11-09, Lucas Nussbaum wrote: > (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.) 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 -- 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/m3oaq4$oef$1...@ger.gmane.org
Re: REISSUED CfV: General Resolution: Init system coupling
Hi, Holger Levsen: > After reading https://www.debian.org/vote/2014/vote_003 in full again […] > […] > I'm also utterly disgusted that this GR was proposed by Ian […] Everybody please take a step back and read >> https://lists.debian.org/debian-project/2014/11/msg2.html before continuing this subthread. In an ideal world, to be frank, you would have done that _instead_of_ starting/continuing this subthread … -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: REISSUED CfV: General Resolution: Init system coupling
Hi, On 09.11.2014 15:08, Lucas Nussbaum wrote: > We have had scenarios in Debian where maintainers, tired of receiving > bug reports about problems on a specific architecture, decided to drop > support for that architecture from their packages. True. Yet we didn't forbid them by GR to do so because that's a vast minority. Why would the init system need a special regulation here? > Not really. Some init systems (at least systemd and upstart) provide > advanced features that are not available in any other init systems. If > this proposal passes, I think that it would be fairly reasonable for > upstreams or maintainers to start making more advanced uses of systemd > service files, and at the same time, remove init scripts when it's not > possible to alter them to match systemd service files functionality. [..] I think that it's important to not just think > about the current state of things, but also look further about what it > would mean in the more distant future. In a more distant future, upstart will be dead and forgotten, as upstream abandoned support for it. At that point it's about discussing whether to use systemd service files or not and I have a hard time to come up with a scenario that couldn't be worked around to a large extent using traditional init scripts, or whatever magic openrc provides, if somebody is willing to take that work. Daemon's service files aren't our problem, really. The problem arises by upstreams that are requiring some other tightly related features provided by systemd exclusively. If upstream decides to go that road I think it's not up to us to cripple their software and provide our users software in a way it was intended to use instead. If that means to exclude a certain fraction of Debian users, that's bad but not our decision. Luckily Debian is "universal" enough to provide other software in our repositories which may fit into the same sport, and may not have such constraints. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: REISSUED CfV: General Resolution: Init system coupling
On 09/11/14 at 14:42 +0100, Arno Töll wrote: > Hi, > > On 09.11.2014 13:36, Lucas Nussbaum wrote: > > With Choice 3, a package maintainer can decide to support only an init > > system that isn't the default if the maintainer considers it a > > prerequisite for its proper operation and no patches > > or other derived works exist in order to support other init systems > > in such a way to render software usable to the same extent. > > Yes. That being said, that's a hypothetical point you're making as we > (hopefully) all agree to > > a) appeal on maintainer's responsibility. I cannot imagine anyone > endorses a particular init system by deliberately excluding users of > other systems unless that would be really necessary for proper operation > and thus leaving no choice but doing so. Why do you think we need more > regulation for best practices that are known to work in Debian already? > We trust developers a lot for a reason. "Proper operation" is not defined in the GR. What if other init systems provided degraded operation, resulting in bug reports from their users? We have had scenarios in Debian where maintainers, tired of receiving bug reports about problems on a specific architecture, decided to drop support for that architecture from their packages. Also, not "usable to the same extent" in the sufficient condition for the maintainer to drop support. > b) it appears that the current "default init system(tm)" is a superset > of other available alternatives, with the lowest common multiple being > sysvinit style scripts, which are supported by all packages that are > providing such start-up scripts, and will continue to do so. Not really. Some init systems (at least systemd and upstart) provide advanced features that are not available in any other init systems. If this proposal passes, I think that it would be fairly reasonable for upstreams or maintainers to start making more advanced uses of systemd service files, and at the same time, remove init scripts when it's not possible to alter them to match systemd service files functionality. > In practice choice 3 allows developers to take advantage of special > features available by the "default init system(tm)" as a last resort > when this is required by the package for proper operation. Yes, choice 3 > would also allow the use of "non-default init system(tm)" exclusive > features when no alternative way to achieve the same exists with the > "default init system(tm)", but really, what could that be, in practice? I agree that, in practice, the scenario of a package starting to require upstart-specific socket activation is unlikely. But given that we are having a GR about this, I think that it's important to not just think about the current state of things, but also look further about what it would mean in the more distant future. Lucas signature.asc Description: Digital signature
Re: Maximum term for tech ctte members
Hi, On 21/10/14 at 17:41 +, Anthony Towns wrote: > Membership of the Technical Committee is automatically reviewed on > the 1st of January of each year. At this time, the terms of the N > most senior members automatically expire provided they were appointed > at least 4.5 years ago. N is defined as 2-R (if R < 2) or 0 (if R >= > 2). R is the number of former members of the Technical Committee who > have resigned, or been removed or replaced within the previous twelve > months. Something just occurred to me. Given the wide range of questions brought to the TC, it makes sense to have some diversity in the TC in order to have expertise at hand covering all the possible questions. Some members might be more familiar with say, porting issues, packages inter-dependencies issues, low-level stuff, desktop environments or might have a tendancy to approach problems with a sysadmin POV, or with a developer POV. When replacing two members at a time, it might be a bit difficult to take that desirable balance into consideration. For example, if there are three candidates A - B - C in the shortlist, and A and B are basically clones in terms of profile, it would make sense to choose (A OR B) AND C. If the final decision is made via a vote, it could require to vote on pairs of candidates. I don't know if this is a problem that can be ignored (because so far, we have always found members with a wide range of expertise) or one that should be addressed somehow. One way to address it would be to serialize the process by re-evaluating membership every 6 months rather than annually, and expiring at most one member at a time. This would add overhead (more frequent renewal processes), but OTOH, once the TC gets used to the fact that frequent renewals are needed, there are ways to optimize the process (such as using the previous list of candidates as a starting point, rather than starting from scratch each time). Lucas -- 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/20141109140839.ga16...@xanadu.blop.info
Re: REISSUED CfV: General Resolution: Init system coupling
Hi, On 09.11.2014 13:36, Lucas Nussbaum wrote: > With Choice 3, a package maintainer can decide to support only an init > system that isn't the default if the maintainer considers it a > prerequisite for its proper operation and no patches > or other derived works exist in order to support other init systems > in such a way to render software usable to the same extent. Yes. That being said, that's a hypothetical point you're making as we (hopefully) all agree to a) appeal on maintainer's responsibility. I cannot imagine anyone endorses a particular init system by deliberately excluding users of other systems unless that would be really necessary for proper operation and thus leaving no choice but doing so. Why do you think we need more regulation for best practices that are known to work in Debian already? We trust developers a lot for a reason. b) it appears that the current "default init system(tm)" is a superset of other available alternatives, with the lowest common multiple being sysvinit style scripts, which are supported by all packages that are providing such start-up scripts, and will continue to do so. In practice choice 3 allows developers to take advantage of special features available by the "default init system(tm)" as a last resort when this is required by the package for proper operation. Yes, choice 3 would also allow the use of "non-default init system(tm)" exclusive features when no alternative way to achieve the same exists with the "default init system(tm)", but really, what could that be, in practice? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: REISSUED CfV: General Resolution: Init system coupling
On 11/09/2014 at 05:26 AM, Jonathan Dowland wrote: > On Sun, Nov 09, 2014 at 04:27:21AM +0100, Michael Meskes wrote: > >> I'd assume he was referring to: >> >>> 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. >> >> This to me reads like the threat Holger mentioned. And for the >> record, I was very surprised to this given the history of the >> decision. > > FWIW, I did not read this as a threat, or at least, I did not read it > as suggesting that Ian himself would participate in this bitter > rearguard action. I read this as meaning Ian suspected that unless > his GR was carried, various anti-systemd people would not be > mollified and their disagreement would percolate down to individual > packages and bugs, rather than being discussed (and potentially > addressed) at a project-wide level. As such, and I'm assuming good > faith on Ian's part here, I think Ian was trying to describe what he > thought was the likely outcome, and not specifically threaten to > behave in a particular way. Thank you. I've been trying to think of a way to clearly express that for some time now, ever since people first started to indicate that they thought this comment was a threat. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: REISSUED CfV: General Resolution: Init system coupling
On 09/11/14 at 13:16 +0100, David Weinehall wrote: > I too value standardization. Judging by decisions taking by other large > distributions and upstream development, a fifth, "only support systemd > as init system" would thus have been the most sensible option. But for > political reasons that's sadly not realistic. > > I read option 3 as saying that all packages have to support the default > init system and *on top of that* they may, at the maintainer's > convenience, support other init systems. Unfortunately that's not how the proposer for Choice 3 reads it. see subthread starting at https://lists.debian.org/debian-vote/2014/10/msg00179.html and specifically https://lists.debian.org/debian-vote/2014/10/msg00181.html With Choice 3, a package maintainer can decide to support only an init system that isn't the default if the maintainer considers it a prerequisite for its proper operation and no patches or other derived works exist in order to support other init systems in such a way to render software usable to the same extent. Lucas signature.asc Description: Digital signature
Re: REISSUED CfV: General Resolution: Init system coupling
On Sun, Nov 09, 2014 at 11:34:20AM +0100, Lucas Nussbaum wrote: [snip] > 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). I too value standardization. Judging by decisions taking by other large distributions and upstream development, a fifth, "only support systemd as init system" would thus have been the most sensible option. But for political reasons that's sadly not realistic. I read option 3 as saying that all packages have to support the default init system and *on top of that* they may, at the maintainer's convenience, support other init systems. This is as close to a more sensible fifth option we're likely to get at the moment. Maybe once things have calmed down and people notice that the moon did not fall just because we changed default init system it might be viable to formally excise sysvinit scripts, but for now I think that option 3 is far better than option 2. Kind regards: David Weinehall -- /) David Weinehall /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- 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/20141109121607.ge8...@hirohito.acc.umu.se
Re: Maximum term for tech ctte members
On 04/11/14 at 15:54 +0100, Stefano Zacchiroli wrote: > - me and Antony discussed various wording possibilities, including at > least two variants: a more mathematical one and one fully in prose. > I've stated my preference among the two, and asked others to comment > on that specific matter. No one did. If you are interested in this > topic, please do. FTR, I have a preference for the mathematical one, as I find it easier to understand. Lucas signature.asc Description: Digital signature
Re: Maximum term for tech ctte members
On Tue, November 4, 2014 15:54, Stefano Zacchiroli wrote: > In the meantime, here is where I think people could help with the > preparation work that needs to be completed before sending out a call > for seconds (if one wants to minimize the risk of fuckups, that is): > > - me and Antony discussed various wording possibilities, including at > least two variants: a more mathematical one and one fully in prose. > I've stated my preference among the two, and asked others to comment > on that specific matter. No one did. If you are interested in this > topic, please do. For me, I can imagine why people didn't feel the need to reply to that question. I really don't mind whether it's formulated in a mathematical style or in English; it's the core substance that counts. Either formulation is acceptable. Given the lack of replies, it seems that there's not much strong preference either way with other -vote readers. Since you seem to have an opinion about it, perhaps you just pick one? > - I've mentioned before that it would be nice to *explicitly* address > the ctte and ask them what they think about the GR text. Of course it > would be inappropriate to offer the ctte a sort of "veto" power on > this GR, and I'm fully convinced they'd refuse such an offer. But this > GR has the potential of being confrontational and cause tension > between project members and tech-ctte members. I think that risk > should be minimized as much as feasible. A formal "what do you think > of this?" question to the tech-ctte is really the bare minimum that > the proposers of this GR should do. > > This item is very actionable: go forward and ask the ctte, summarize > answers received, report back to -project. (Although it has a > dependency on the previous item.) We're certain that committee members are subscribed to debian-vote, members have participated in this thread, and the committee as a whole is well aware of this discussion, as evidenced from their last meeting notes. Therefore there has been (and still is) ample room for their input on the proposal and we need not worry that they are obvlivious of it going on. Requiring some extra round of querying and summarising therefore just seems like a request for busywork. Cheers, This -- 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/05f7192b88b9f334fa7e18b0a1b6cdec.squir...@aphrodite.kinkhorst.nl
Re: REISSUED CfV: General Resolution: Init system coupling
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 >T
Re: REISSUED CfV: General Resolution: Init system coupling
On Sun, Nov 09, 2014 at 04:27:21AM +0100, Michael Meskes wrote: > I'd assume he was referring to: > > > 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. > > This to me reads like the threat Holger mentioned. And for the record, I was > very surprised to this given the history of the decision. FWIW, I did not read this as a threat, or at least, I did not read it as suggesting that Ian himself would participate in this bitter rearguard action. I read this as meaning Ian suspected that unless his GR was carried, various anti-systemd people would not be mollified and their disagreement would percolate down to individual packages and bugs, rather than being discussed (and potentially addressed) at a project-wide level. As such, and I'm assuming good faith on Ian's part here, I think Ian was trying to describe what he thought was the likely outcome, and not specifically threaten to behave in a particular way. -- 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/20141109102640.gc29...@chew.redmars.org
