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
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 There may be some loss of
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: 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: 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 t...@debian.org /) 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: 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 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
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 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 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
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
On 2014-11-09, Lucas Nussbaum lu...@debian.org 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: Maximum term for tech ctte members
Lucas == Lucas Nussbaum lu...@debian.org 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
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 Diziet bdale: The GR is going to be another 3 weeks. 17:14:09 Diziet We should decide on the automatic switch before then IMO 17:15:30 Diziet 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 dondelelcaro 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 dondelelcaro Diziet: at least, not while the GR is happening which seems to directly address this part of the question 17:34:28 Diziet dondelelcaro: That's not the question. The question is whether it's something that would pass a TC vote. 17:34:32 Diziet I'm done with consensus decisionmaking. 17:35:34 Diziet 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 dondelelcaro Diziet: we can always go to majoritarian, but if we can agree, so much the better. 17:37:17 Diziet 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: 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]
[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]
* 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: 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]
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 Diziet bdale: The GR is going to be another 3 weeks. 17:14:09 Diziet 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 Diziet 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 dondelelcaro 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 dondelelcaro Diziet: at least, not while the GR is happening which seems to directly address this part of the question 17:34:28 Diziet dondelelcaro: That's not the question. The question is whether it's something that would pass a TC vote. 17:34:32 Diziet I'm done with consensus decisionmaking. 17:35:34 Diziet 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 dondelelcaro Diziet: we can always go to majoritarian, but if we can agree, so much the better. 17:37:17 Diziet 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;
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 gregkh at linuxfoundation.org: 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]
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
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]
Josh == Josh Triplett j...@joshtriplett.org 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
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: 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
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: 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: 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
