Re: Maximum term for tech ctte members
On Fri, Nov 07, 2014 at 10:34:13AM +0100, Stefano Zacchiroli wrote: > I've briefly discussed this off list with Sam Hartman, who proposed a > sensible rationale (although not necessarily the same Antony had in > mind). The rationale is avoiding suddenly under staffing the ctte too > much, making it non functional. Personally, I'm not terribly worried about the size of the ctte; I don't think having just a couple of active members would be much less effective than havin eight active members. (Though having only a couple of members might significantly lower the odds of having any /active/ members) > I understand the concern, but I think it could be addressed better. For > instance, one could say that expiries of "young" members inhibit the > expiry of an "old" member only if the latter expiry would reduce the > size of the ctte below 4 members (which is some sort of minimally viable > threshold for a function ctte, according to Constitution ?6.2.1). In all > other situations, "old" member expiries proceed unaffected by how many > other members of the ctte stepped down in the previous year. That sounds plausible; I'm not convinced it's a problem worth solving though. The downside of solving it is that it makes things more complicated, and potentially introduces annoying loopholes or bad incentives. The only bad incentive I see off hand is that if there were only four members then the oldest members would be discouraged from appointing new members, because that could force them to expire and otherwise they could stay on indefinitely. But that's counterbalanced by the clause letting the DPL appoint two new ctte members without even having to consult the ctte. But if the DPL's going to exercise that power anyway, why have any exception at all for resignations? Just have the two oldest members expire each year, provided they've served at least four years? *oldest = longest serving Cheers, aj -- 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/20141109055518.gb7...@master.debian.org
Re: Maximum term for tech ctte members
On Tue, Nov 04, 2014 at 03:54:26PM +0100, Stefano Zacchiroli wrote: > - I haven't mentioned it yet publicly (still due to ENOTIME), but I > still have mixed feelings about the provision that allows "younger" > ctte members to step down, inhibiting the expiry of "older" members. > I'm not necessarily against that, but I'm struggling to understanding > its rationale. > Antony: can you remind us what the rationale is? > Others: how do you feel about that? When first posted, there was concern that continuity is a good thing and having a large proportion of the ctte expire at the same time would be a bad thing: - Tollef: https://lists.debian.org/debian-project/2014/05/msg00057.html - Stefano: https://lists.debian.org/debian-project/2014/05/msg00059.html - Brian: https://lists.debian.org/debian-project/2014/05/msg00082.html So based on Russ's comment of: "The primary goal of this sort of system is to rotate fresh people through the decision-making body." - https://lists.debian.org/debian-project/2014/05/msg00055.html I figured it might work to switch from the goal of "constant max term" to "constant rate of change over": "If we want the opportunity to appoint new members regularly, rather than expire old members per se, we could just say that: "on July 1st, the two longest serving ctte members' term expires" to end up with (on average) four year terms... Probably needs some tweaking though -- maybe it ought only apply if nobody's resigned in the previous 12 months or something. - https://lists.debian.org/debian-project/2014/05/msg00061.html They're both reasonable "principles" in my opinion; the only question between them is how you balance continuity/disruption against rate of progress. I don't personally have much of a preference either way. Note that the "worst case" scenario would be something like: - Keith, Colin, Russ, Don, Steve, Andi all quit from the tech ctte effective Dec 30th - Jan 1st rolls around - Are Bdale and Ian removed? The "can't rejoin for 12 months" rule would prevent any of them from being immediately reappointed, and the tech ctte would have to be reconstituted from all new members by the DPL at that point. Is it better to have some continuity in the form of Bdale and Ian still being around? (I don't really have a preference; maybe if they knew Bdale and Ian would disappear too, that'd be enough to prevent a couple of other members from quitting in the first place) Cheers, aj -- 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/20141109053508.ga7...@master.debian.org
Re: REISSUED CfV: General Resolution: Init system coupling
On Sun, Nov 09, 2014 at 01:24:16AM +0100, Jakub Wilk wrote: > >I'm also utterly disgusted that this GR was proposed by Ian, someone who > >perceives himself as loser of the tech-ctte decision (instead of accepting > >a group decission of a group which he is part of) and thus deciced to beat > >Debian into shape via this GR > > You can't decide such a thing single-handedly. Are you also disgusted that > 11 people seconded Ian's proposal? What? He can't decide ingle-handedly that he's disgusted? Which content do I miss? > >- and who has already announced that he will not keep quiet if he looses > >the GR and only will be quiet if he wins. > > Presumably you're referring to > <21595.36886.724024.723...@chiark.greenend.org.uk>. Oh wait, no. 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. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- 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/20141109032721.ga4...@feivel.credativ.lan
Re: REISSUED CfV: General Resolution: Init system coupling
Hi again, after re-reading these threads to find that message-id I missed to reply to this: On Sonntag, 9. November 2014, Jakub Wilk wrote: > You can't decide such a thing single-handedly. Are you also disgusted > that 11 people seconded Ian's proposal? no, not at all. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: REISSUED CfV: General Resolution: Init system coupling
Hi Jakub, On Sonntag, 9. November 2014, Jakub Wilk wrote: > I'm afraid that if you want to conduct a personal attack on Ian, you > have to try a little bit harder. I'm not interested in personally attacking Ian. At all. But I do think his _behaviour_ has been quite unacceptable and also I think it would have been worse if I had written "some tech-ctte member" or something like this and avoided naming him. I had such a draft and to me it looked much better when I added his name. Elephant in the room also came to my mind… > Presumably you're referring to > <21595.36886.724024.723...@chiark.greenend.org.uk>. Oh wait, no. Indeed. I ment https://lists.debian.org/21585.4657.229360.683...@chiark.greenend.org.uk > >(I'm happy to provide the message-id for this... but I'm sure people do > >rememeber.) > Please do provide it. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: REISSUED CfV: General Resolution: Init system coupling
Hi Holger, I'm afraid that if you want to conduct a personal attack on Ian, you have to try a little bit harder. * Holger Levsen , 2014-11-08, 20:46: I'm also utterly disgusted that this GR was proposed by Ian, someone who perceives himself as loser of the tech-ctte decision (instead of accepting a group decission of a group which he is part of) and thus deciced to beat Debian into shape via this GR You can't decide such a thing single-handedly. Are you also disgusted that 11 people seconded Ian's proposal? - and who has already announced that he will not keep quiet if he looses the GR and only will be quiet if he wins. Presumably you're referring to <21595.36886.724024.723...@chiark.greenend.org.uk>. Oh wait, no. (I'm happy to provide the message-id for this... but I'm sure people do rememeber.) Please do provide it. -- Jakub Wilk -- 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/20141109002416.ga5...@jwilk.net
Re: Re: REISSUED CfV: General Resolution: Init system coupling
Get real man. This is a very important issue in the whole free software world. Freedom of choice or not, especially for *nix*. -- 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/1415485595.2857.2.ca...@kth.se
Re: REISSUED CfV: General Resolution: Init system coupling
Hi, After reading https://www.debian.org/vote/2014/vote_003 in full again, I came to the conclusion that I wanted to publically withdraw my support for Choice 2, after re-reading it several times and sleeping over it. So why do I dislike choice 2? 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 begin part 2 There may be some loss of functionality under sysvinit if that loss is considered acceptable by the package maintainer and the package is still basically functional, but Debian's standard requirement to support smooth upgrades from wheezy to jessie still applies, even when the system is booted with sysvinit. end part 2 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. And part 2 is too vague and broad at the same time, and also unrealistic given the circumstances (eg wanting to release in 2015). Again, I think these words aim and prioritize a rather unimportant (and unspecific) feature (and whats a smooth upgrade anyway? IMO a reboot is part of a smooth upgrade as only after a reboot I know the system can be rebooted safely...) and take away the opportunity to do the right thing instead. Choice 2 is certainly better than choice 1, which completly unacceptably tells maintainers they have to support (and provide) a removed legacy upstream feature. Or better: invent a new system which they have no interest to create. IOW: those who believe in choice 1 think they can tell others to write patches (and how!). Which is soo much out of bounds with Debians ideals and practices since over 20 years that I'm speechless. I'm also utterly disgusted that this GR was proposed by Ian, someone who perceives himself as loser of the tech-ctte decision (instead of accepting a group decission of a group which he is part of) and thus deciced to beat Debian into shape via this GR - and who has already announced that he will not keep quiet if he looses the GR and only will be quiet if he wins. (I'm happy to provide the message-id for this... but I'm sure people do rememeber.) This makes me quite very sad. From a responsible and reasonable tech-ctte member I would have expected (and I still expect!) to see the bias and act accordingly, as in: step back. cheers, Holger signature.asc Description: This is a digitally signed message part.
