Re: Amendment: Keep e-mail while allowing other options in addition [Re: GR: Hide Identities of Developers Casting a Particular Vote]
On Fri, 25 Feb 2022, Sam Hartman wrote: > I'm supportive of a change here, and let's see if we can work out > something that we both like. IN particular, I agree with the > following: > > 1) As long as it make sense, we should continue to support email voting. [...] > However, I don't think it should take a 3:1 super majority to change > how we collect votes. I don't want it to take a 3:1 majority to add additional methods (web based, I'm presuming), but I think not allowing a signed (and/or encrypted) emailed ballot to count should require a 3:1 majority. [The former potentially allows more valid voters to vote, the latter potentially reduces who can vote.] [...] > And yes, I agree with you that a lot of the ways I personally would > work on fixing that problem would still make it easy to accept email > ballots. Worst case, the secretary would just have to set up two voting systems, and import the results from one system into the other. [Kind of a pain, but at least until we have a few votes under our belts with a new system, it seems warranted. If I'm wrong, and everyone prefers the new system, and there are no (or acceptable few) e-mailed votes, a constitutional amendment should be easy.] [...] > So, I'm wondering whether it would be enough to make it clear that > changing the voting system beyond doing what we do for DPL discussions > requires adequate project consensus. [...] > 2) In the General resolution system, in addition to the constitutional > amendment, include a statement of the day asking the secretary to > obtain sufficient project consensus before changing how voting works. The secretary would still have to run a vote to make a statement of the day, so it might as well still require a supermajority. [Alternatively, we could write in a self-deleting section which only required a majority to remove its effect... but that seems complicated.] On Sat, 26 Feb 2022, Kurt Roeckx wrote: > I plan to look at least at belenios is voting by email is no longer > required. My plan is to run at least a small test to see if people > like it or not. I could maybe also run a larger poll. But we'll see > about how we pick a different system, or not, later. Looks interesting. I know (having hacked up devotee to make pocket-devotee) that the plumbing around these systems is complicated; I'd certainly love to see a solution which has a larger community contributing to it. -- Don Armstrong https://www.donarmstrong.com Fate and Temperament are two words for one and the same concept. -- Novalis [Hermann Hesse _Demian_]
Amendment: Keep e-mail while allowing other options in addition [Re: GR: Hide Identities of Developers Casting a Particular Vote]
I propose the following amendment to this ballot option, which if rejected I propose as its own option: modified english/devel/constitution.wml @@ -266,7 +266,8 @@ earlier can overrule everyone listed later. -Votes are cast in a manner suitable to the Secretary. +Votes are cast by email in a manner suitable to the Secretary. + Non-email methods suitable to the Secretary may be used in addition to e-mail. The Secretary determines for each poll whether voters can change their votes. https://salsa.debian.org/don/webwml/-/commit/9bbc20fed6881fa5b239830cad0939b979bbe300 Rationale: e-mail should continue to be an option for casting votes even while alternative methods of casting ballots might also be allowed. -- Don Armstrong https://www.donarmstrong.com We cast this message into the cosmos. [...] We are trying to survive our time so we may live into yours. We hope some day, having solved the problems we face, to join a community of Galactic Civilizations. This record represents our hope and our determination and our goodwill in a vast and awesome universe. -- Jimmy Carter on the Voyager Golden Record signature.asc Description: PGP signature
Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public
On Mon, 14 Feb 2022, Richard Laager wrote: > On 2/14/22 09:53, Sam Hartman wrote: > > Steve certainly found feedback he got to be harassment. > > I did as well. > > I received some harassment (not a lot, but some) over this too. My > recollection is this was coming from non-DDs. Without minimizing the totally unacceptable harassment that occurred, all three of you seconded the proposals and were significantly more visible than a voter listed on the tally page. [...] > Secret ballots are certainly not a panacea that solves all harassment, > but they may be a risk reduction measure. I see this as a possibility. I'm personally most concerned about someone who isn't able/willing to vote because they feared harassment. I'm likely biased because I'm in a privileged position and rarely have to deal with concerted harassment directed specifically at me, so I might be minimizing the real fear people have because I personally haven't experienced it. Perhaps the compromise position is to default to secret ballots, but allow people to automatically unmask their preference at the appropriate time. [Totally not supported by devotee currently, but certainly possible to enable.] -- Don Armstrong https://www.donarmstrong.com The solution to a problem changes the problem. -- Peer's Law
Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public
On Sun, 13 Feb 2022, Sam Hartman wrote: > >>>>> "Don" == Don Armstrong writes: > Don> If we make all votes secret we should require that the voting > Don> system used enables voters to validate that their vote was > Don> correctly recorded and tabulated in the final vote count. > > Note that our current constitution does not require this for DPL votes. > Do you think this is important enough to require in the constitution? > I'm guessing yes since you bring it up, but I want to ask explicitly. Yes. [If there wasn't discussion of replacing e-mail and devotee, I wouldn't bother, since devotee already has this property.] > Don> We should also enable independent tabulation,[1] which you get > Don> automatically when votes are not secret. [Devotee enables this > Don> currently as well, but future non-devotee systems might not.] > > Would you be willing to propose a merge request for these two properties > if you think it is important that we require them in the constitution? I missed that §4.2.3 already requires this, though it probably needs to be clarified. Let me work up a merge this. -- Don Armstrong https://www.donarmstrong.com Vimes hated and despised the privileges of rank, but they had this to be said for them: At least they meant that you could hate and despise them in comfort. -- Terry Pratchett _The Fifth Elephant_ p111
Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public
On Sun, 13 Feb 2022, Sam Hartman wrote: > 1) Do not make the identity of a voter casting a particular vote > public. If we make all votes secret we should require that the voting system used enables voters to validate that their vote was correctly recorded and tabulated in the final vote count. The existing system for DPL votes has this property, but future systems might not. We should also enable independent tabulation,[1] which you get automatically when votes are not secret. [Devotee enables this currently as well, but future non-devotee systems might not.] I'd also appreciate hearing more specific examples of where someone wasn't able to vote their true preference because the vote was public. I currently plan to offer (or second) an amendment to this proposal which strikes the section making all votes private and rank that higher than one which struck it, but I'm open to be convinced otherwise. My personal reasoning is that I see my role as a voting project member as more of a stewardship role where I'm trying to decide what is best for the project, rather than what is best for me personally, and I want to be seen as being a good steward for the project. I also think the large number of voters masks the impact of a single individual vote. [But maybe this is a personal safety issue? Perhaps people should be able to optionally mask their identity when voting? Not sure.] 1: Where someone can take each individual vote and calculate the results themselves. -- Don Armstrong https://www.donarmstrong.com You could say to the Universe this is not /fair/. And the Universe would say: Oh it isn't? Sorry. -- Terry Pratchett _Soul Music_ p357
Re: Secret Ballots: Handling Disagreement with the Secretary
On Fri, 04 Feb 2022, Sam Hartman wrote: > I see two ways of reading section 4.1.7: > > 1) If the DPL and secretary disagree on any issue then the project can > replace the secretary. > > 2) If the DPL and secretary disagree on the only issue where the two > of them both get to have an opinion (namely who is the next > secretary), the project decides. > > So it's not clear to me that section 4.1.7 allows the secretary to be > replaced out of cycle. If we had a big conflict with the secretary, > I'd obviously argue for interpretation 1, but that aspect of the > constitution is not so clear to me. I think the plainest reading is #1, but I can see the argument that #2 was the intention. > Don> If we add this, the intersection of §4.1.8 and §4.1.7 should be > Don> addressed when it comes to questions requiring a supermajority. > > I don't understand what you mean here. Are you worried that the > project might replace the secretary with a 1:1 majority to get around > a determination that some ballot option required a 3:1 majority? Yes. I think the additional complexity of requiring a 3:1 majority to overrule the secretary isn't enough to always have the desired effect if §4.1.7 isn't also modified accordingly. That said, if a majority uses the blunt force of §4.1.7 to try to get its way by removing people, I'd be more concerned about the health of the project than whether we had written rules to prevent it. -- Don Armstrong https://www.donarmstrong.com Herodotus says, "Very few things happen at the right time, and the rest do not happen at all. The conscientious historian will correct these defects". -- Mark Twain _A Horse's Tail_
Re: Secret Ballots: Handling Disagreement with the Secretary
On Sat, 29 Jan 2022, Sam Hartman wrote: > So, to be specific, I propose to add a paragraph 8 to section 4.1 > (powers of the developers): > > 8. Override a decision of the secretary. Overriding the secretary's >determination of the majority required for a ballot option or >overriding the determination of the outcome of a vote requires that >the developers agree by a 3:1 majority. The secretary's >determination of whether a 3:1 majority is required to override >the project secretary is not itself subject to override. I see the intention here. My initial thought is that the constitution already enables overriding by replacing the secretary through §4.1.7, assuming the project leader and secretary disagree. [§4.1.1 (recalling the DPL) could be employed if they agree.] If we add this, the intersection of §4.1.8 and §4.1.7 should be addressed when it comes to questions requiring a supermajority. -- Don Armstrong https://www.donarmstrong.com No matter how many instances of white swans we may have observed, this does not justify the conclusion that all swans are white. -- Sir Karl Popper _Logic of Scientific Discovery_
Re: GR: Change the resolution process (corrected)
On Sat, 20 Nov 2021, Russ Allbery wrote: >1. Any member of the Technical Committee may propose a resolution. > This creates an initial two-option ballot, the other option > being the default option of "Further discussion." The proposer > of the resolution becomes the proposer of the ballot option. Suggest making this "None of the above" instead of "Further discussion" to avoid two different default options for TC decisions vs project decisions. > Add a new paragraph to the start of 6.3.2 following "Details regarding > voting": > >Votes are decided by the vote counting mechanism described in >section §A.5. The voting period lasts for one week or until the >outcome is no longer in doubt assuming no members change their >votes, whichever is shorter. Members may change their votes until >the voting period ends. There is a quorum of two. The Chair has a >casting vote. The default option is "Further discussion." Same as above. > Strike "The Chair has a casting vote." from the existing text and make the > remaining text a separate, second paragraph. I'm assuming the intention is to remove the duplication of "The Chair has a casting vote", right? [That's what I understood, but textual descriptions of text edits are challenging.] Because of this (and others), can I suggest that the ballot option be specified as a wdiff to the existing constitution? Whoever has to modify the constitution at the end of this vote will likely appreciate it. -- Don Armstrong https://www.donarmstrong.com He was wrong. Nature abhors dimensional abnormalities, and seals them neatly away so that they don't upset people. Nature, in fact, abhors a lot of things, including vacuums, ships called the Marie Celeste, and the chuck keys for electric drills. -- Terry Pratchet _Pyramids_ p166
Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
On Sun, 18 Apr 2021, Barak A. Pearlmutter wrote: > If we look at the actual ballots, it's really interesting. Options 7 > and 8 were semantically pretty much equivalent. It's hard to see any > reason for someone to rank them very differently. 7 was a decision to not issue a statement ["There's no statement on this issue that I want Debian to issue"]. 8 was a decision for further discussion ["There may be statement on this issue that I'd want Debian to issue, but it's not here."] When there isn't an explicit "no decision" option on the ballot, further discussion encompass both, but that is not the case here. > It's very difficult to imagine someone who actually preferred option 7 > being equally satisfied with any of options 1-6 and 8. Here's an example thought process that works: "I want Debian to stop discussing this issue and anything more that Debian does on this issue is equally bad." Or another one: "I know that I prefer this option, but I'm not comfortable with the rest of the options to decide what the project should do, so I'll defer to the project's judgement." Not to say that there aren't voters who are confused, but you should contact them to figure out why they voted the way they did before assuming that they didn't know what they were doing. -- Don Armstrong https://www.donarmstrong.com Whatever you do will be insignificant, but it is very important that you do it. -- Mohandas Karamchand Gandhi
Re: more GRs to come
On Wed, 10 Aug 2016, Micha Lenk wrote: > On Tue, Aug 09, 2016 at 02:33:34PM -0700, Don Armstrong wrote on the > debian-private list: > > You're being very rude to every DD who participated in the discussion on > > -vote, the secretary, and myself by claiming that we intended to mislead > > you. > > Sorry, this was ment to be a joke. I do not believe that you intended > to mislead me, so please accept my apologies. Accepted; sorry that I made such a big deal about it. -- Don Armstrong https://www.donarmstrong.com Given that the odds of a miracle are one in one million, and events which could be a miracle happen every second, the odds of not seeing a miracle in a month are less than 8 in 100. Clearly miracles are not all that miraculous.
Re: Amendment to Proposed GR: Declassifying parts of -private of historical interest
On Mon, 08 Aug 2016, Bart Martens wrote: > On Mon, Aug 08, 2016 at 09:58:45AM -0500, Don Armstrong wrote: > > On Sun, 07 Aug 2016, Micha Lenk wrote: > > > That would establishing some kind of "ex post facto" law (which by the > > > way is prohibited in many constitutions for good reasons). I really > > > don't want to leave the decision whether past messages will be > > > affected or not up to the list masters. > > > > This is why the GR text requires that at minimum DDs can object via GR. > > I don't see how that covers Micha's concern. It makes it so that the decision whether a particular set of messages or quotes is released publicly isn't solely up to listmaster@ or another DPL delegate. At minimum, DDs can object by GR. > In fact there is no way of preventing declassification since the > outcome of a GR is unknown in advance. I don't follow you here; that a GR could potentially go against you doesn't mean that the outcome of the GR is meaningless. > I think it's plain wrong that we're now about to give a permission for > declassifying debian-private possibly against the authors' will. GR > 2005/vote_002 did include "requests by the author of a post for that > post not to be published will be honored" while 2016/vote_002 does not > include any means for the original authors to prevent > declassification. I envision that anyone who is delegated to do the declassification will include something along those lines. But they are in the best position to decide how to do that, if that ever happens. -- Don Armstrong https://www.donarmstrong.com America was far better suited to be the World's Movie Star. The world's tequila-addled pro-league bowler. The world's acerbic bi-polar stand-up comedian. Anything but a somber and tedious nation of socially responsible centurions. -- Bruce Sterling, _Distraction_ p122
Re: Amendment to Proposed GR: Declassifying parts of -private of historical interest
On Sun, 07 Aug 2016, Micha Lenk wrote: > That would establishing some kind of "ex post facto" law (which by the > way is prohibited in many constitutions for good reasons). I really > don't want to leave the decision whether past messages will be > affected or not up to the list masters. This is why the GR text requires that at minimum DDs can object via GR. -- Don Armstrong https://www.donarmstrong.com Your absence has gone through me Like thread through a needle. Everything I do is stitched with its color. -- W. S. Merwin "Poetry in Motion" p107
Re: Amendment to Proposed GR: Declassifying parts of -private of historical interest
On Mon, 18 Jul 2016, Kurt Roeckx wrote: > On Sun, Jul 17, 2016 at 05:56:12PM -0700, Don Armstrong wrote: > > In response to the helpful comments, I've modified my proposed amendment > > to Nicolas's resolution by adding "at minimum", and now propose the > > following amendment: [...] > So this amendment has been accepted, and we currently have 2 > options. Thanks, Kurt! Nicolas: just for the avoidance of doubt, feel free to accept (or not accept) this amendment as you see fit. [If any of the seconders of the original proposal object to this amendment, now would also be a reasonable time to do so.] -- Don Armstrong https://www.donarmstrong.com Americans can always be counted on to do the right thing, after they have exhausted all other possibilities. -- W. Churchill
Amendment to Proposed GR: Declassifying parts of -private of historical interest
In response to the helpful comments, I've modified my proposed amendment to Nicolas's resolution by adding "at minimum", and now propose the following amendment: === BEGIN GR TEXT === Title: Declassifying parts of -private of historical interest 1. The 2005 General Resolution titled "Declassification of debian-private list archives" is repealed. 2. Debian listmasters and/or other individuals delegated by the DPL to do so are authorized to declassify excerpts of -private of historical interest by any process which at minimum provides sufficient time and opportunity for Debian Developers to object by GR prior to declassification. 3. In keeping with paragraph 3 of the Debian Social Contract, Debian Developers are strongly encouraged to use the debian-private mailing list only for discussions that should not be disclosed. === END GR TEXT === -- Don Armstrong https://www.donarmstrong.com There are two types of people in this world, good and bad. The good sleep better, but the bad seem to enjoy the waking hours much more. -- Woody Allen signature.asc Description: PGP signature
Re: Amendment to Proposed GR: Declassifying parts of -private of historical interest
On Sat, 16 Jul 2016, Iain Lane wrote: > (GRs are, of course, always going to be on the table regardless.) The procedure and declassification could potentially occur to quickly for a GR to intervene. I don't expect listmasters or any delegate to actually do that, though. On Sat, 16 Jul 2016, Nicolas Dandrimont wrote: > I'm very close to seconding it. However, I wonder why, in the second phrase, > you're restricting the process of objecting to declassification to a GR. The text doesn't restrict the objection process to a GR, but to require that a GR could occur. On Sat, 16 Jul 2016, Stefano Zacchiroli wrote: > Can you clarify which is which Don? My intention was to ensure there was enough time and opportunity for Developers to object before each declassification at minimum. A public vote over potentially declassifying e-mails would be bad, but I trust that listmaster@ or anyone who gets delegated by the DPL will follow a procedure which addresses this issue before it gets to the point that such a GR is required. Perhaps the following adjustment: 2. Debian listmasters and/or other individuals delegated by the DPL to do so are authorized to declassify excerpts of -private of historical interest by any process which [+ at minimum +] provides sufficient opportunity for Debian Developers to object by GR prior to declassification. communicates this more effectively and addresses that concern? -- Don Armstrong https://www.donarmstrong.com The beauty of the DRUNKENNESS subprogram was that you could move your intoxication level up and down at will, instead of being caught on a relentless down escalator to bargain basement philosophy and the parking garage. -- Rudy von Bitter _Software_ p124
Amendment to Proposed GR: Declassifying parts of -private of historical interest
I hereby propose the following amendment to the currently proposed GR. === BEGIN GR TEXT === Title: Declassifying parts of -private of historical interest 1. The 2005 General Resolution titled "Declassification of debian-private list archives" is repealed. 2. Debian listmasters and/or other individuals delegated by the DPL to do so are authorized to declassify excerpts of -private of historical interest by any process which provides sufficient opportunity for Debian Developers to object by GR prior to declassification. 3. In keeping with paragraph 3 of the Debian Social Contract, Debian Developers are strongly encouraged to use the debian-private mailing list only for discussions that should not be disclosed. === END GR TEXT === -- Don Armstrong https://www.donarmstrong.com Our days are precious, but we gladly see them going If in their place we find a thing more precious growing A rare, exotic plant, our gardener's heart delighting A child whom we are teaching, a booklet we are writing -- Frederick Rükert _Wisdom of the Brahmans_ [Hermann Hesse _Glass Bead Game_] signature.asc Description: PGP signature
Re: Proposed GR: Acknowledge that the debian-private list will remain private
On Thu, 07 Jul 2016, Russ Allbery wrote: > Don Armstrong <d...@debian.org> writes: > > > I have no problem acknowledging that we haven't been able to implement > > the existing GR, but I don't see the utility of voting to remove the > > possibility of ever implementing it. > > I would prefer removing the possibility of ever implementing it > without another vote. We can always vote again if someone comes up > with a workable scheme. That puts a whole lot of stop energy in front of anyone who actually is interested in trying to declassify -private, though; they'd have to come up with a method, bikeshed the method, and then propose a vote which still might not succeed. I know that the vote to disallow declassifying anything before 2008 stopped me from working on this when I was interested in understanding the early project history. Going forward, another alternative is to: 1) Keep the method for the archives; it sucks, but it doesn't really hurt anything. 2) All messages to -private will be declassified within 3 years with the exception of: a) [VAC] messages b) messages with [PRIVATE] in the subject; all such messages must be PGP signed with a key in the keyring or they will be rejected by the mailing list software. -- Don Armstrong https://www.donarmstrong.com This isn't life in the fast lane, it's life in the oncoming traffic -- Terry Pratchett
Re: Proposed GR: Acknowledge that the debian-private list will remain private
On Thu, 07 Jul 2016, Nicolas Dandrimont wrote: > The acknowledgement is about failing to implement the existing GR, > being honest about it, and to let us move on from it. I have no problem acknowledging that we haven't been able to implement the existing GR, but I don't see the utility of voting to remove the possibility of ever implementing it. I don't see how we could ever declassify -private without this amendment as the previous vote had an alternative to declassify mails before 2005 which failed, [I should note too, that I've attempted on one or two occasions to go through and declassify -private, but the process required was far too clunky.] Therefore, I'm contemplating proposing an amendment to this proposed GR which either acknowledges that we have failed to declassify -private for the time being, or gives listmaster@ the ability to define a published procedure for the automated declassification of private. Possible text for the former here: === BEGIN GR TEXT === Title: Acknowledge that Debian has failed to declassify debian-private 1. Debian acknowledges that it has failed to declassify debian-private, and that this is unlikely to change at any point in the future. 2. In keeping with paragraph 3 of the Debian Social Contract, Debian Developers are strongly encouraged to use the debian-private mailing list only for discussions that should not be disclosed. === END GR TEXT === -- Don Armstrong https://www.donarmstrong.com There is no mechanical problem so difficult that it cannot be solved by brute strength and ignorance. -- William's Law
Re: General Resolution: Fix Minor Bugs in Constitution
On Mon, 26 Oct 2015, Sam Hartman wrote: >- GENERAL RESOLUTION STARTS - > > >Constitutional Amendment: TC Supermajority Fix > >Prior to the Clone Proof SSD GR in June 2003, the Technical >Committee could overrule a Developer with a supermajority of 3:1. > >Unfortunately, the definition of supermajorities in the SSD GR has a >off-by-one error. In the new text a supermajority requirement is met >only if the ratio of votes in favour to votes against is strictly >greater than the supermajority ratio. > >In the context of the Technical Committee voting to overrule a >developer that means that it takes 4 votes to overcome a single >dissenter. And with a maximum committee size of 8, previously two >dissenters could be outvoted by all 6 remaining members; now that >is no longer possible. > >This change was unintentional, was contrary to the original intent >of the Constitution, and is unhelpful. > >For the avoidance of any doubt, this change does not affect any >votes (whether General Resolutions or votes in the Technical >Committee) in progress at the time the change is made. > >Therefore, amend the Debian Constitution as follows: > > Index: doc/constitution.wml > === > --- doc/constitution.wml(revision 10982) > +++ doc/constitution.wml(working copy) > @@ -913,7 +913,7 @@ > > >An option A defeats the default option D by a majority > - ratio N, if V(A,D) is strictly greater than N * V(D,A). > + ratio N, if V(A,D) is greater or equal to N * V(D,A) and > V(A,D) is strictly greater than V(D,A). > > >If a supermajority of S:1 is required for A, its majority > ratio > > > > > > >Constitutional Amendment: Fix duplicate section numbering. > >The current Debian Constitution has two sections numbered A.1. >This does not currently give rise to any ambiguity but it is >undesirable. > >Fix this with the following semantically neutral amendment: > > - Renumber the first section A.1 to A.0. > > >- GENERAL RESOLUTION ENDS - Seconded. -- Don Armstrong http://www.donarmstrong.com signature.asc Description: Digital signature
Re: In plain English please?! Re: General resolution: Changes to the Standard Resolution Procedure
On Mon, 31 Aug 2015, Dimitri John Ledkov wrote: > On 31 August 2015 at 08:06, Kurt Roeckx - Debian Project Secretary > <secret...@debian.org> wrote: > > Hi, > > > > A new GR has been started to update the Standard Resolution > > Procedure. Details about it can be found on: > > https://www.debian.org/vote/2015/vote_002 > > > > I'm failing to understand the current situation, nor proposed changes. > Can someone please give a plain English explanation and/or examples? > > E.g. committee of size N is voting on an issue I which happens to be > overriding developer. The votes are F for, A against, S abstentions. > Previously this would fail, now this will pass. If the votes were 6 for (F), 2 against (A), 0 abstensions (S) for a resolution which required 3:1 majority, currently, such a resolution would not pass. This changes it so that it would. This isn't usually an issue in general votes, but is a problem on the CTTE. -- Don Armstrong http://www.donarmstrong.com I'm sorry about those late night emails. I only said those things because I was too drunk to be afraid. -- a softer world #579 http://www.asofterworld.com/index.php?id=579
Re: More women in key positions ?
On Tue, 31 Mar 2015, Charles Plessy wrote: If the discussion here would be about reforming the TC, I would propose that the nominations should be public, just as for the DPL election. I have no problem with people nominating themselves publicly, but I don't want to require public nominations. DPL nominees have to be public because the DPL is elected by the project at large. However, the topic here is the DPL election, hence my question is focused on what the DPL can do, and one possible action is to use the appointment process to push for more women in the TC. My point is that the appointment process is not the appropriate lever to use, and a candidate who planned to use it as a lever would rank lower for me.[1] The underlying problem of unequal representation in Debian is a serious issue. But before reaching for this as a solution, someone should probably ask people why they did not want to serve on the TC.[2] 1: Of course, if the TC was overlooking nominees on the basis of their gender or other non-relevant factors, then the DPL would be within their rights to request the TC reconsider the slate. 2: Admittedly, I've been meaning to ask people about this myself, but haven't had time. -- Don Armstrong http://www.donarmstrong.com Fate and Temperament are two words for one and the same concept. -- Novalis [Hermann Hesse _Demian_] -- 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/20150331161428.gh14...@teltox.donarmstrong.com
Re: More women in key positions ?
On Sun, 29 Mar 2015, Charles Plessy wrote: Given the role of the Project leader in appointing members of the technical committee, one possibillity would be to delay appointments of new members until the technical committee recommends at least one woman. In order for the TC to recommend someone, they must first be nominated and accept, or nominate themselves. Claiming that the lack of women on the TC can be resolved simply by forcing the TC to do so is simplistic. It also seems to me to be insulting to the many highly skilled women in Debian with whom I would be happy to serve on the TC with, had they been interested in serving. -- Don Armstrong http://www.donarmstrong.com J.W. Grant: Bastard! Rico: Yes, Sir. In my case, an accident of birth. But you, Sir, you're a self-made man. -- Henry Rico Fardan in The Professionals -- 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/20150329045308.gw14...@teltox.donarmstrong.com
Re: draft alternative proposal: fix problem at the root
On Thu, 04 Dec 2014, Michael Gilbert wrote: Doesn't that require constitutional change? The current powers as written make the TC a decision-making body, not a mediation body. Not really, because it doesn't take any constitutional powers to try to mediate. -- Don Armstrong http://www.donarmstrong.com [C]haos is found in greatest abundance wherever order is being sought. It always defeats order, because it is better organized. -- Terry Pratchett _Interesting Times_ p4 -- 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/20141204060218.ga4...@teltox.donarmstrong.com
Re: [DRAFT] Maximum term for tech ctte members
On Tue, 18 Nov 2014, Stefano Zacchiroli wrote: On Tue, Nov 18, 2014 at 10:41:13PM +1000, Anthony Towns wrote: provided /they/ were appointed This is still pending, and noted in BUGS. I agree this is as a potential problem, at least if you look at it from a paranoid angle. I find your suggested wording not immediate, though, and I wonder if a/ someone else has better suggestion, and b/ whether this is worth fixing. Maybe this: diff --git a/constitution.txt.new b/constitution.txt.new index 96245cf..fb5ac4a 100644 --- a/constitution.txt.new +++ b/constitution.txt.new @@ -305,10 +305,10 @@ remove or replace an existing member of the Technical Committee. 7. Term limit: 1. Membership of the Technical Committee is automatically -reviewed on the 1st of January of each year. At this time, the -terms of the 2 most senior members automatically expire -provided they were appointed at least four and a half years -(54 months) ago. +reviewed on the 1st of January of each year. At this time, +the terms of the 2 most senior members who were most +recently appointed at least 54 months ago automatically +expire. 2. A member of the Technical Committee is said to be more senior than another if they were appointed earlier, or were appointed at the same time and have been a member of the Debian Project -- 2.1.1 Also, one of the things that would also be nice to fix is to make the max number of CTTE members 9 instead of 8, to avoid the casting vote problem when the CTTE is full. I don't believe that we should force the CTTE to have an odd number, because that is complicated, and may not be worth the effort, either. This patch is simple, but: diff --git a/constitution.txt.new b/constitution.txt.new index 96245cf..85f0043 100644 --- a/constitution.txt.new +++ b/constitution.txt.new @@ -288,9 +288,9 @@ 6.2. Composition -1. The Technical Committee consists of up to 8 Developers, and should +1. The Technical Committee consists of up to 9 Developers, and should usually have at least 4 members. -2. When there are fewer than 8 members the Technical Committee may +2. When there are fewer than 9 members the Technical Committee may recommend new member(s) to the Project Leader, who may choose (individually) to appoint them or not. 3. When there are 5 members or fewer the Technical Committee may -- 2.1.1 But if this is at all controversial, then we can put this forward later. -- Don Armstrong http://www.donarmstrong.com LEADERSHIP -- A form of self-preservation exhibited by people with autodestructive imaginations in order to ensure that when it comes to the crunch it'll be someone else's bones which go crack and not their own. -- The HipCrime Vocab by Chad C. Mulligan (John Brunner _Stand On Zanzibar_ p256-7) -- 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/20141118202142.gz4...@rzlab.ucr.edu
Re: [DRAFT] Maximum term for tech ctte members
On Tue, 18 Nov 2014, Holger Levsen wrote: (FWIW, I _think_ I prefer an even number here... and despite labeling this a game changer I'm not sure I care that much about this change... arg and this might sound like it could be misunderstood again...) The real reason to use an odd number is to avoid having to use the casting vote in the CTTE. Considering that we've used the casting vote exactly once in the entire history of Debian, I'm not sure that including this is worth the effort if even one person disagrees. -- Don Armstrong http://www.donarmstrong.com You could say she lived on the edge... Well, maybe not exactly on the edge, just close enough to watch other people fall off. -- hugh macleod http://www.gapingvoid.com/Moveable_Type/archives/000309.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/20141118205723.gc4...@rzlab.ucr.edu
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: Call for Votes: General Resolution: Init system coupling
On Tue, 04 Nov 2014, Lucas Nussbaum wrote: On 04/11/14 at 17:53 +, Neil McGovern wrote: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 57dd4d7c-3e92-428f-8ab7-10de5172589e [ ] Choice 1: Packages may not (in general) require a specific init system [ ] Choice 2: Support alternative init systems as much as possible [ ] Choice 3: Packages may require specific init systems if maintainers decide [ ] Choice 4: General Resolution is not required [ ] Choice 5: Further Discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- Why not just make Choice 2: Packages should support sysvinit for jessie. Otherwise, if you all aren't able to agree, just: Choice 1: Proposal Choice 2: Amendment A Choice 3: Amendment B Choice 4: Amendment C Choice 5: Further Discussion and we can get on with the voting. -- Don Armstrong http://www.donarmstrong.com People selling drug paraphernalia ... are as much a part of drug trafficking as silencers are a part of criminal homicide. -- John Brown, DEA Chief -- 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/20141104213018.gx24...@rzlab.ucr.edu
Re: How about always sending a copy of proposals, amendements, secondes etc. to the Secretary ?
On Wed, 05 Nov 2014, Charles Plessy wrote: Would it help to amend point 4.2.5 of our constitution, to request that in addition to the announcement on a publicly-readable electronic mailing list, a copy of proposals, amendments, sponsors, etc. must also be sent to the Secretary ? It seems unfair to request the Secretary to read each and every email on debian-vote... Those of us who propose amendments and proposals should really propose a ballot option name, amendment, and figure out who seconded the proposals and just send them to the secretary in wml suitable for direct inclusion in the appropriate vote_nnn.wml file. I don't think it's necessary to actually amend the constitution to do this, because it's just something that we can do. -- Don Armstrong http://www.donarmstrong.com Religion is religion, however you wrap it, and like Quell says, a preoccupation with the next world clearly signals an inability to cope credibly with this one. -- Richard K. Morgan Broken Angels p65 -- 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/20141105024555.gb24...@rzlab.ucr.edu
Re: Maximum term for tech ctte members
On Mon, 03 Nov 2014, Sam Hartman wrote: A TC meeting is a meeting where only the TC members are speaking. That's not really the right forum for such a decision to be taken. Just to echo Russ's comments, all that we really discussed was that as the CTTE, we weren't going to press forward for this to happen while the other GR was being actively discussed/voted on. The CTTE has no power to stop anyone (including those on the CTTE) from proposing, seconding, or discussing this amendment. Personally, I agree that having multiple active discussion/second periods on debian-vote is problematic. Right; that's what we seemed to agree on as well. I think that we can all agree that we'd like a decision on this amendment significantly before January 1st, which presumably means having it formally proposed well before December 3rd. -- Don Armstrong http://www.donarmstrong.com I really wanted to talk to her. I just couldn't find an algorithm that fit. -- Peter Watts _Blindsight_ p294 -- 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/20141104002700.ge23...@teltox.donarmstrong.com
Re: Maximum term for tech ctte members
I think rotation is a good idea. My main minor concern is that it doesn't allow reappointing members to the CTTE if there are no nominees whom the DPL and CTTE finds acceptable (or even if there are no nominees at all). Not allowing people to be reappointed if there are nominees and they're just not acceptable may be a design goal, but not allowing reappointment if there are no nominees does not. On Wed, 22 Oct 2014, Anthony Towns wrote: + li +pA Developer is not eligible to be appointed to the Technical Committee +if they have been a member within the previous 12 months./p + /li + [...] + + li +pMembership of the Technical Committee is automatically reviewed +on the 1st of January of each year. At this time, any member of the +Technical Committee who was most recently appointed 54 or more months +prior will ordinarily have their term automatically expire. However, +a member's term may be extended until the next review provided Probably should be will be extended instead of may be extended. +there are at least two other members, each of whom who either (a) +are a current, longer serving member of Technical Committee, or (b) +resigned from the Technical Committee, or were removed or replaced +since the previous review./p + +pciteWhen the Committee is fully populated, it is expected this +will result in a turnover of 1 or 2 members each year, whether by +resignation or term expiry, while allowing senior members to stay +on if a junior member resigns./cite/p + /li /ol There was also some discussion of this during the CTTE meeting too: http://meetbot.debian.net/debian-ctte/2014/debian-ctte.2014-07-31-16.58.log.html Thanks for drafting this. -- Don Armstrong http://www.donarmstrong.com Miracles had become relative common-places since the advent of entheogens; it now took very unusual circumstances to attract public attention to sightings of supernatural entities. The latest miracle had raised the ante on the supernatural: the Virgin Mary had manifested herself to two children, a dog, and a Public Telepresence Point. -- Bruce Sterling, _Holy Fire_ p228 -- 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/20141021153428.gm28...@teltox.donarmstrong.com
Re: GR proposal: code of conduct
On Mon, 24 Feb 2014, Thijs Kinkhorst wrote: It may make sense to publish bans in-band in the medium where they apply as much as possible. ML bans are sent to a mailinglist, IRC bans can be viewed already via the IRC protocol; probably it would also make sense if bans on the web forum would also somehow be registered in the context of that forum. Alternatively, I would be OK with a mailbox (say b...@debian.org) which could be mailed by teams which enacted the bans. It would be trivial to enact a IRC bot to handle this for IRC[1], and it wouldn't be a huge deal for me as owner@bdo or listmaster@ldo to Cc: bans to such an address instead of debian-private. [Anyone who actually cared about bans could arrange to have a cronjob mail any new bans to them.] 1: I sort of want this already for #debian on both OFTC and FN, but my lack of copious free time has prevented me from even starting... -- Don Armstrong http://www.donarmstrong.com Religion is religion, however you wrap it, and like Quell says, a preoccupation with the next world clearly signals an inability to cope credibly with this one. -- Richard K. Morgan Broken Angels p65 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140225053004.gl16...@teltox.donarmstrong.com
Re: GR proposal: code of conduct
On Wed, 12 Feb 2014, Ean Schuessler wrote: It is well understood that secret laws and secret courts are not a desirable feature for any government. I feel that the same should hold true for our community. The procedures leading up to a ban, the evidence collected, the criteria the evidence must meet and the persons making the final decision should all be public record. I reference the Social Contract mandate to not hide problems in support of this concept. The reason why listmaster@l.d.o and ow...@b.do do not disclose or discuss bans in public are because: 1) We wish to avoid negative connotations from someone being temporarily banned being attached to the person after they have rectified their behavior 2) In the case where some agent is clearly trolling or otherwise engaging in attention seeking behavior, posting publicly just adds additional indication of this behavior. That said, for owner@b.d.o, everything regarding a ban is sent to owner@b.d.o which is available to all DDs, and bans are announced to debian-priv...@lists.debian.org I hope many of you will agree that while the CoC may be a necessary feature for our community it should be governed in a transparent, policy-driven and unbiased manner with detailed record keeping and peer review. I don't believe too detailed of a procedure is going to be feasible without dramatically wasting listmaster@, owner@, IRC operators, and wiki admin's time. We certainly can publish bans on -private, and I'm OK with there being review after the fact if necessary, but I'm not personally going to waste my limited time with a burdensome bureaucratic procedure to actually put the ban in place in the first case. -- Don Armstrong http://www.donarmstrong.com An elephant: A mouse built to government specifications. -- Robert Heinlein _Time Enough For Love_ p244 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140212194355.gs5...@teltox.donarmstrong.com
Re: [all candidates] Removing or limiting DD rights?
This message appears to be more appropriate for -project, non-candidate responses, please follow up there. On Thu, 28 Mar 2013, Chris Knadle wrote: As a bug reporter dealing with a misbehaving maintainer, this is what I would want: 1. A clear place to report the misbehavior ow...@bugs.debian.org is an appropriate place to report abusive behavior by anyone (maintainers, users, etc) on the BTS. Likewise, listmas...@lists.debian.org is an appropriate place to report abusive behavior by anyone in messages to lists. This probably should be better documented somewhere on the website, but as I've never had to look for it, I don't know where that would be. Someone who has searched for it and failed may have some better suggestions. 2. A set of guidelines maintainers should follow I certainly wouldn't have a problem with adopting a set of guidelines for interactions on the BTS, but I'd prefer to have these guidelines discussed on -project first. [We already do have guidelines for the mailing list, too.] 3. A public dialog about the misbehavior with some Debian authority along with the misbehaving maintainer. Note on (3): In the cases I've dealt with, the misbehavior was in public bug reports, so the discussion of the misbehavior should likewise be public. Discussion of misbehavior is usually not public. If someone reports bad behavior, owner@ or listmaster@ typically talks to the individual concerned, and warns them about it specifically, and informs the reporter that their concern has been addressed. In the case where owner@ or listmaster@ have made a decision which can be overridden by GR (IE, banning someone from using control@ or similar), -private is notified so DDs are aware. Don Armstrong -- S: Make me a sandwich B: What? Make it yourself. S: sudo make me a sandwich B: Okay. -- xkcd http://xkcd.com/c149.html http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130328223540.gq5...@teltox.donarmstrong.com
Re: General Resolution: Diversity statement
On Thu, 10 May 2012, Jakub Wilk wrote: * Debian Project Secretary - Kurt Roeckx secret...@debian.org, 2012-05-08, 23:28: http://www.debian.org/vote/2012/vote_002 Hmm. According to this page, the proposal[0] was seconded by Steve Langasek. However, Steve seconded only the draft[1], which has different wording. As the proposer accepted these changes (or originally made them), and Steve has not objected under §A.1.5 or §A.1.6, that doesn't really affect anything. [And based on the number of seconds, the only thing that would happen is resetting the discussion period to exactly the same period we have now.] Don Armstrong -- Everyone has to die. And in a hundred years nobody's going to inquire just how most people died. The best thing is to do it in the way that strikes your fancy most. -- Kenzaburō Ōe _Silent Cry_ p5 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012051957.gu3...@rzlab.ucr.edu
Re: Rationale for GRs
On Fri, 11 Mar 2011, Matthew Vernon wrote: In the interests of fairness, those opposed to a proposal but not wishing to amend it should also be allowed a rationale. My suggestion here would be that A set of DDs (equivalent to the requirement for amendments) could have an opposing rationale added to the GR; I would envisage only one of these per GR. I think this is the sort of thing that can be done on an ad-hoc basis; the secretary can decide to nominate a rationale and a rebuttal to the rationale for each option, indicating who signs on to the rationale and rebuttal on the appropriate vote page. [Or just link to the appropriate point in the -vote archives where the rationale and rebuttal were posted.] Don Armstrong -- LEADERSHIP -- A form of self-preservation exhibited by people with autodestructive imaginations in order to ensure that when it comes to the crunch it'll be someone else's bones which go crack and not their own. -- The HipCrime Vocab by Chad C. Mulligan (John Brunner _Stand On Zanzibar_ p256-7) http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110311193427.gn23...@teltox.donarmstrong.com
Re: Naming of non-uploading DDs (Was: GR: welcome non-packaging contributors as Debian project members)
On Thu, 16 Sep 2010, Stefano Zacchiroli wrote: Kurt, my inclination was to consider this change as falling under Constitution §A.1.3 as a change that does not alter the meaning of the proposal. Since you don't actually need seconders under §4.2.1, and you are the proposer of the original option, I don't think it's necessary (unless a seconder wants to propose the original proposal as a second amendment.) And in any case, any change is allowed by the original proposer of a particular amendment; it just resets the discussion period unless it meets A.1.6. [Though one of these days, we probably should fix up A.1; it's language doesn't properly promote amendments to resolutions (options?) to be voted on.] Don Armstrong -- The sheer ponderousness of the panel's opinion [...] refutes its thesis far more convincingly than anything I might say. The panel's labored effort to smother the Second Amendment by sheer body weight has all the grace of a sumo wrestler trying to kill a rattlesnake by sitting on it---and is just as likely to succeed. -- Alex Kozinski, Dissenting in Silveira v. Lockyer (CV-00-00411-WBS p5983-4) http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100916171006.gn28...@teltox.donarmstrong.com
Re: Questions for all candidates: decentralization of power
On Fri, 19 Mar 2010, Clint Adams wrote: 4) The tech-ctte has the power to appoint its own members. I do not know why they should be allowed to self-manage when their judgment on the issues raised to them has often been less-than-stellar. [...] If there are decisions which are less-than-stellar, the proper method to address them is to have a GR under 4.1.4. Is there any legitimate reason why core teams should be allowed to select their own members with or without external oversight? In the case of the CTTE, §4.1.3 and §4.1.4 allows the developers to have oversight over all of the decisions that the CTTE takes, including membership in the CTTE. Don Armstrong -- NASCAR is a Yankee conspiracy to keep you all placated so the South won't rise again. -- http://www.questionablecontent.net/view.php?comic=327 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100319194619.gt4...@teltox.donarmstrong.com
Bug#574059: Provide link to SPI meeting minutes and/or treasurer reports in appropriate (TBD) location
Package: debian-www Severity: wishlist On Tue, 16 Mar 2010, Stefano Zacchiroli wrote: On Mon, Mar 15, 2010 at 11:13:02PM +0100, Martin Zobel-Helas wrote: SPI's Treasurer, Michael Schultheiss, (and by the way Debian Developer) does a really good job by sending out monthly Treasurer's Reports which are in every monthly meeting minutes linked from http://www.spi-inc.org/corporate/meeting-minutes That, together with the fact that I can't find any reference to that link on *.debian.org, is why I thought it was not public. I believe a lot of other DDs do not know about that link, in fact a couple of people which asked me my draft platform stared at my gross figure of Debian total money and asked me « are you sure this information is public? ». I honestly never thought about it myself, but it's fairly trivial to file a bug asking for it (and someone who has a better idea than I do right this second of where it should go could even prepare and/or commit a patch. Don Armstrong -- She was alot like starbucks. IE, generic and expensive. -- hugh macleod http://www.gapingvoid.com/Moveable_Type/archives/001376.html http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100316005848.gz4...@teltox.donarmstrong.com
Re: Question to all Candidates: 2IC
On Sat, 13 Mar 2010, Margarita Manterola wrote: There are a bunch listed in my yet-to-be-published platform. But just to give an example from the previous mail, I'd like to have a page with rankings of people reporting and fixing bugs, in order to give some nice Debian merchandise to the ones that help the most, but I don't think I'd have the time to organize the whole thing myself. This is actually something that I've been meaning to get to for quite a while; if there is someone who is interested in working on this and/or helping me to get it whipped up into shape, I'd appreciate the help. [I had asked Steve about this in Argentina, and he was supportive, but unfortunatly I haven't done anything more about it since then.] Don Armstrong -- This message brought to you by weapons of mass destruction related program activities, and the letter G. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100314021850.gu20...@volo.donarmstrong.com
Re: Debian Project Leader Elections 2010: Call for nominations
On Thu, 04 Mar 2010, Debian Project Secretary - Kurt Roeckx wrote: The new project leader term starts on Saturday the 17th of April, 2010. The time line looks like: | Period | Start| End| |+--+| | Nomination | Friday, March 5th, 2010 | Thursday, March 11th, 2010 | | Campaign | Friday, March 12th, 2010 | Thursday, April 1st, 2010 | | Vote | Friday, April 2th, 2010 | Thursday, April 15th, 2010 | Unless there is significant clamoring,[0] I once again will refrain from running a Debate on IRC.[1] Don Armstrong 0: Significant clamoring would probably involve someone stepping up to help, too. 1: Considering that there's only one self nomination, and we're within 48 hours of the gate, this message may be moot, anyway. -- A Bill of Rights that means what the majority wants it to mean is worthless. -- U.S. Supreme Court Justice Antonin Scalia http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100309213309.gp20...@volo.donarmstrong.com
Re: Overriding vs Amending vs Position statement
On Fri, 01 May 2009, Luk Claes wrote: A position statement is a decided on proposal that clarifies the position of the Debian project, but does not explicitly amend a foundation document. [...] So I don't really see what we should vote on unless someone disagrees with above interpretations? The only question resides with the effect of passing such position statements. Without modifying foundation documents or the constitution, they are effectively non-binding advisory statements when operating within areas that are the remit of foundation documents or the constitution. Developers can ignore (or follow) such statements as they wish. Furthermore, the statements must be non-technical. Don Armstrong -- Filing a bug is probably not going to get it fixed any faster. -- Anthony Towns http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Overriding vs Amending vs Position statement
On Fri, 01 May 2009, Manoj Srivastava wrote: If the statements are in contradiction of the foundation document (which is the case in a couple of prior situations), then are you saying that anything in the foundation documents can ve worked around by putting out a position statement, and have the developers proceed to ignore the foundation document on that basis? No. I'm in fact saying that developers can ignore the position statement on that basis. if that is not the case, what value does a position statement in contradiction of a foundation document mean? Next to no value, as far as I'm concerned. How binding _are_ the foundation documents? Only as binding as we as a group consider them to be. Since the language they're written in is ambiguous, we can have reasonable differences of opinion as to what the foundation documents actually mean. A position statement about the foundation documents only serves to state what a majority of the project thinks the documents say; it doesn't change what the documents actually say.[1] As such, people who think differently are free to ignore the position statement in carrying out their duties (though they can of course be overridden by GR.) Don Armstrong 1: Fundamentally though, I find the whole process of making position statements about the foundation documents tedious. If you think the documents meaning is unclear, propose amendments to the documents to make them clearer. -- I really wanted to talk to her. I just couldn't find an algorithm that fit. -- Peter Watts _Blindsight_ p294 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Overriding vs Amending vs Position statement
On Fri, 01 May 2009, Manoj Srivastava wrote: On Fri, May 01 2009, Don Armstrong wrote: Only as binding as we as a group consider them to be. Hmm. Certainly puts the social contract in a new light, though. It really shouldn't; as a group we decide whether we're going to uphold the social contract. There's no way to force the group to uphold it. [Given the anguish with which we struggle on -project and -vote to figure out what the SC says, it's seems clear that large numbers of us feel that we should be upholding the SC.] As such, people who think differently are free to ignore the position statement in carrying out their duties (though they can of course be overridden by GR.) Oh. So this is a way, via two simple majority GR's, for any majority to do an end run around the 3:1 constitutional requirements? nifty. Sure. If we as a project are headed towards self-destruction, there's really no way for the constitution to stop us. We always have to fall back on the continued desire of developers to work together to create the most technically excellent, free operating system possible. Don Armstrong -- This message brought to you by weapons of mass destruction related program activities, and the letter G. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: All candidates: Membership procedures
On Wed, 25 Mar 2009, Lucas Nussbaum wrote: Something else that would be interesting to store in UDD is the full bug logs, as it would allow to list the comments that someone posted to bugs. That's expensive, but maybe we could only store a subset of information, like the From, Date, and Subject fields. You can already get this with http://bugs.debian.org/cgi-bin/pkgreport.cgi?correspondent=lu...@lucas-nussbaum.net (or the appropriate Debbugs::SOAP::get_bugs(correspondent='foo'); call, or bts select correspondent:lu...@lucas-nussbaum.net) Don Armstrong -- The solution to a problem changes the problem. -- Peer's Law http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposal: Enhance requirements for General resolutions
On Sat, 21 Mar 2009, Don Armstrong wrote:
I'm going to make suggestions for changes to both proposals here; just
change 2*floor(Q) to floor(Q) for the second alternative. Note that
I've switched from floor(2Q) to 2*floor(Q); this changes the majority
requirements from 31 to 30, which is what the extended rationale said
as an example.
Truncated wdiff output that implements this is below, diff attached.
H34.2. Procedure/H3
OL
LI
PThe Developers follow the Standard Resolution Procedure, below. A
resolution or amendment is introduced if proposed by any Developer and
sponsored by at least [-K-] {+2*floor(Q)+} other Developers, or if proposed
by
the Project Leader or the Technical Committee./P
/LI
LI
PDelaying a decision by the Project Leader or their Delegate:/P
OL
LIIf the Project Leader or their Delegate, or the Technical
Committee, has made a decision, then Developers can override them
by passing a resolution to do so; see s4.1(3)./LI
[-LIIf such-]
{+LIWhen+} a resolution [-is-] {+has been+} sponsored by at least
[-2K-] {+floor(Q)+} Developers,
or if it is proposed by the Technical Committee, the resolution puts
the decision immediately on [-hold (provided-] {+hold, provided+} that
resolution itself says [-so)./LI
LIIf the original decision was to change a discussion period or
a voting period, or the resolution is to override the Technical
Committee, then only K Developers need to sponsor the resolution
to be able to-]
{+that it will+} put the decision [-immediately-] on [-hold./LI-]
{+hold immediately./LI+}
[...]
LI
PQ is half of the square root of the number of current Developers. [-K-]
{+floor(Q)+} is [-Q-] {+the nearest integer less than+} or [-5, whichever-]
{+equal to Q. 2*floor(Q)+} is [-the smaller.-]
{+two times floor(Q).+} Q [-and K-] need not be [-integers-] {+an integer+}
and [-are-] {+is+} not rounded./P
/LI
/OL
Don Armstrong
--
Religion is religion, however you wrap it, and like Quell says, a
preoccupation with the next world clearly signals an inability to cope
credibly with this one.
-- Richard K. Morgan Broken Angels p65
http://www.donarmstrong.com http://rzlab.ucr.edu
--- gr_mod_second.wml.orig 2009-03-22 17:17:38.0 -0700
+++ gr_mod_second.wml.new 2009-03-22 17:25:46.0 -0700
@@ -2,10 +2,10 @@
OL
LI
-PThe Developers follow the Standard Resolution Procedure, below.
-A resolution or amendment is introduced if proposed by any
-Developer and sponsored by at least K other Developers, or if
-proposed by the Project Leader or the Technical Committee./P
+PThe Developers follow the Standard Resolution Procedure, below. A
+resolution or amendment is introduced if proposed by any Developer and
+sponsored by at least 2*floor(Q) other Developers, or if proposed by
+the Project Leader or the Technical Committee./P
/LI
LI
@@ -16,15 +16,10 @@
Committee, has made a decision, then Developers can override them
by passing a resolution to do so; see s4.1(3)./LI
- LIIf such a resolution is sponsored by at least 2K Developers,
- or if it is proposed by the Technical Committee, the resolution
- puts the decision immediately on hold (provided that resolution
- itself says so)./LI
-
- LIIf the original decision was to change a discussion period or
- a voting period, or the resolution is to override the Technical
- Committee, then only K Developers need to sponsor the resolution
- to be able to put the decision immediately on hold./LI
+ LIWhen a resolution has been sponsored by at least floor(Q) Developers,
+ or if it is proposed by the Technical Committee, the resolution puts
+ the decision immediately on hold, provided that resolution itself says
+ that it will put the decision on hold immediately./LI
LIIf the decision is put on hold, an immediate vote is held to
determine whether the decision will stand until the full vote on
@@ -68,8 +63,8 @@
/LI
LI
-PQ is half of the square root of the number of current
-Developers. K is Q or 5, whichever is the smaller. Q and K need not
-be integers and are not rounded./P
+PQ is half of the square root of the number of current Developers.
+floor(Q) is the nearest integer less than or equal to Q. 2*floor(Q) is
+two times floor(Q). Q need not be an integer and is not rounded./P
/LI
/OL
Re: Proposal: Enhance requirements for General resolutions
I'm going to make suggestions for changes to both proposals here; just change 2*floor(Q) to floor(Q) for the second alternative. Note that I've switched from floor(2Q) to 2*floor(Q); this changes the majority requirements from 31 to 30, which is what the extended rationale said as an example. Also, I don't believe that §4.2.3 is required if we're going to have the same procedure for both voting procedure changes, ctte overrides, and other general overrides Finally, I've modified the language of §4.2.2 slightly to make it clear that the proposal needs to explicitly say that it puts the delegate's decision on hold to avoid any need for the secretary to have to interpret whether it does or does not. On Sat, 21 Mar 2009, Joerg Jaspert wrote: Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] a) §4.2.1 is changed to read: The Developers follow the Standard Resolution Procedure, below. A resolution or amendment is introduced if proposed by any Developer and sponsored by at least 2*floor(Q) other Developers, or if proposed by the Project Leader or the Technical Committee. b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. b) §4.2.2 is changed to read: When a resolution has been sponsored by at least floor(Q) Developers, or if it is proposed by the Technical Committee, the resolution puts the decision immediately on hold, provided that resolution itself says that it will put the decision on hold immediately. c) §4.2.3 is deleted. c) the definition of K gets erased from the constitution. [§4.2(7)] d) §4.2.7 is changed to read: Q is half of the square root of the number of current Developers. floor(Q) is the nearest integer less than or equal to Q. 2*floor(Q) is two times floor(Q). Q need not be an integer and is not rounded. e) §4.2 is renumbered to remain in sequence. Don Armstrong -- Vimes hated and despised the privileges of rank, but they had this to be said for them: At least they meant that you could hate and despise them in comfort. -- Terry Pratchett _The Fifth Elephant_ p111 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DPL Debates [Re: Debian Project Leader Election 2009]
On Mon, 09 Mar 2009, Joerg Jaspert wrote: If someone can't set up a poll, I'll send another message asking for DDs to privately mail me (or maybe me-too to -vote) if they find the debates useful. http://doodle.com/nmpesn9t5fwv6ewe Having this run for 7 days now, we had 72 participants. The question asked was Are the Debian DPL IRC Debates useful and should we keep them? and people could chose Yes, No, I don't care, never looked at one. and we have Yes 34 No 32 Don't care 12 Based on these results, my own personal thoughts, and some brief discussion with the candidates, I'm leaning heavily towards not expending the effort on a debate this time around. I think much more could be gained from good discussions about the platforms here in -vote, and followups with the candidates on IRC (Sledge [Steve] and zack [Stefano] are highly active on IRC) than the debate itself. Also, since Stefano and Steve are in similar timezones, odds are good that you all can get them to engage each other on #debian-devel on an ad-hoc basis about the specific questions that bother you specifically, without having to wait for the rigamarole of an IRC debate. Don Armstrong -- People selling drug paraphernalia ... are as much a part of drug trafficking as silencers are a part of criminal homicide. -- John Brown, DEA Chief http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
DPL Debates [Re: Debian Project Leader Election 2009]
On Sat, 21 Feb 2009, Debian Project Secretary wrote: | Period | Start| End| |+--+| | Nomination | Sunday, March 1st, 2009 | Saterday, March 7th, 2009 | | Campaign | Sunday, March 8th, 2009 | Saterday, March 28th, 2009 | | Vote | Sunday, March 29th, 2009 | Saterday, April 11th, 2009 | I suggest that potential DPL candidates start getting their platform ready. I would like to receive them before the campaign period start. As I've apparently volunteered to moderate the debate again,[0] it falls to me to remind prospective candidates to calculate their schedule for the week of the 21st-28th, and soon after they self nominate forward the times during that week which they can absolutely not debate as well as times that they'd rather not debate to me. [This will help me to avoid having to schedule the debate smack in the middle of some erstwhile candidate's coffin time.[0.577]] Those who have suggestions for alterations to the format can also make those known in a reply to this message (refer to last year's debate format[1] if you've forgotten what we did last year, suffer from amnesia or are incapable of forming long term memories or faking them by the creative use of google and blogs). People who'd like to help run the debate and/or collect questions can also volunteer with a message to -vote. Don Armstrong 0: I know I should heed my major professor's most important lesson learned from his military service: never be first, never be last, never volunteer... but I always seem to fall asleep before the conclusion is reached. 0.577: Deity forbid that the day star attack you.[1.618] 1: http://svn.donarmstrong.com/don/trunk/projects/debian/dpl_debates/debate_rules_public.txt 1.618: Yes, for some reason I've adopted irrational footnote numbering. Don't ask why.[2.718] 2.718: Ok... it has something to do with NIH R01 grant deadlines and collaborators who are incapable of using LaTeX+BibTeX, and want to make me (more) insane instead. [3.14] 3.14: Imagine a pithy footnote here. I've given up and gone to the pub. -- Every gun that is made, every warship launched, every rocket fired signifies in the final sense, a theft from those who hunger and are not fed, those who are cold and are not clothed. This world in arms is not spending money alone. It is spending the sweat of its laborers, the genius of its scientists, the hopes of its children. This is not a way of life at all in any true sense. Under the clouds of war, it is humanity hanging on a cross of iron. -- Dwight Eisenhower, April 16, 1953 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DPL Debates [Re: Debian Project Leader Election 2009]
On Fri, 27 Feb 2009, Steve Langasek wrote: I'd like to raise the question of whether these IRC debates are really something we should have. I know Don and the panelists put a lot of time and effort into making the debates happen, which is part of why I ask the question: is it really worth all this effort? What do we get out of a three-hour real-time IRC debate that we don't already get from the candidates' platforms and three weeks of discussion on debian-vote? I know that I personally learn a lot, but that's primarily as a consequence of having to prepare to ask non-naive questions. I'm not sure if a me-too thread would be the right way to do this, but I'd certainly be glad to know if it's something that people find useful and intersting, because there's no question that doing the debate consumes at least 30 person-hours of work with all of the participants. [And I could easily spend the 5-6 hours that it takes me to do them making debbugs better.] Perhaps someone could set up a poll for DDs to indicate whether they find the debates useful or not? [I think Jeroen was doing this last?] If someone can't set up a poll, I'll send another message asking for DDs to privately mail me (or maybe me-too to -vote) if they find the debates useful. Don Armstrong -- I was thinking seven figures, he said, but I would have taken a hundred grand. I'm not a greedy person. [All for a moldy bottle of tropicana.] -- Sammi Hadzovic [in Andy Newman's 2003/02/14 NYT article.] http://www.nytimes.com/2003/02/14/nyregion/14EYEB.html http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Sun, 04 Jan 2009, Chris Waters wrote: Because not wanting any of the options, but still having (strong) opinions on which are more and which are less desirable is still a valid position--one I find myself in frequently IRL. It's fine to rank options you prefer further discussion to, because that's a valid preference. It expresses: I'd rather die a painless death now than die a painful death now, but I'd rather have further discussion than either of those options. That doesn't mean that you should second either of those options to get them to appear on the ballot. You don't want either of them to happen, so the ideal ballot has neither, and if enough supporters of either want them to happen, they'll second those options themselves. if I actually would prefer further discussion, but am still willing to compromise and have opinions about which of the options I don't like are better than others, what should I do? Express your opinion on them when voting, but don't second them. If a majority doesn't prefer them to further discussion, those options will be discarded due to majority; having options that a majority doesn't prefer to further discussion on a ballot is a waste of time. An even more painful waste of time is options which not even 1.5Q people prefer to further discussion, because those options had no chance at all of being selected. If they actually represent options that will pass the FD majority hurdle, people who actually prefer those options to FD will second them, and will easily be able to meet K, and should be able to meet Q or 2Q. Don Armstrong -- Science is a way of trying not to fool yourself. The first principle is that you must not fool yourself, and you are the easiest person to fool. -- Richard Feynman What is and What Should be the Role of Scientific Culture in Modern Society; 1964 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Sat, 03 Jan 2009, Chris Waters wrote: On Fri, Jan 02, 2009 at 09:17:28AM +1100, Ben Finney wrote: (Don has, after subsequent argument, modified this to “… that you don't plan on ranking above Further Discussion”.) Bad, bad idea! What if you are planning to rank Further Discussion as 1, but staill have a compromise you'd be willing to accept that you think is _far_ better than anything _else_ that's been proposed? If you're willing to accept a compromise, you rank it above further discussion. The very point of ranking FD above an option is to indicate that you don't find a specific option an acceptable solution at all, and would rather have futher discussion than accepting it. Don Armstrong -- Of course, there are cases where only a rare individual will have the vision to perceive a system which governs many people's lives; a system which had never before even been recognized as a system; then such people often devote their lives to convincing other people that the system really is there and that it aught to be exited from. -- Douglas R. Hofstadter _Gödel Escher Bach. Eternal Golden Braid_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Sat, 03 Jan 2009, Chris Waters wrote: Part of the problem is that we never have no, just no on our ballots, so the only alternative is to vote further discussion, even if you have no interest whatsoever in any further discussion, and, as far as you're concerned, the matter is settled. You can easily propose and/or second an option that reaffirms the status quo if you think the matter should be settled completely. If not enough people second it, then the status quo isn't acceptable to enough people in the project for it to be a viable option. So, if it's harder to add options, people are more likely to vote for choices they really don't like. (I know that I have.) The idea is to make it more difficult to add options so that options that have no chance of winning are not added. Secondarily, it's to try to get people to spend more time in the deliberation stage to perfect the options and achieve compromise before an option ends up on the ballot. Ideally this will mean that we'll have options that represent large parts of the project, with compromises that are acceptable to all of the project, with no options that are only acceptable to small parts of the project. Don Armstrong -- The attackers hadn't simply robbed the bank. They had carried off everything portable, including the security cameras, the carpets, the chairs, and the light and plumbing fixtures. The conspirators had deliberately punished the bank, for reasons best known to themselves, or to their unknown controllers. They had superglued doors and shattered windows, severed power and communications cables, poured stinking toxins into the wallspaces, and concreted all of the sinks and drains. In eight minutes, sixty people had ruined the building so thoroughly that it had to be condemned and later demolished. -- Bruce Sterling, _Distraction_ p4 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Fri, 02 Jan 2009, MJ Ray wrote: Sorry - I'm with Wouter Verhelst on this. Having options on the ballot that only a small minority of DDs support can help resolve conflicts: it lays them to rest, demonstrating they fail in the wider DD population, If an option can't get seconds enough to pass K (or Q), it doesn't have support in the DD population or the proposers are lazy, and don't want to find enough support. In either case, people's time shouldn't be wasted with the effort required to run a vote and vote in it. rather than the DDs supporting them being able to blame the self-selecting subset who participate on debian-vote. If DDs who support them are unable to gather enough seconds via -vote, nothing stops them from finding other people who support the proposal using other methods. Furthermore, there are at least 103 DDs subscribed to -vote[1], so arguments about some self-selecting subset are a bit misplaced (not that that'll stop them from being made.) Even if the number of seconds for a proposal is raised to something massive like 2Q, would it be worth keeping the number of seconds for a partial amendment at K? If we're going to have the trouble of votes, we might as well vote as comprehensively as possible... Additional options on a ballot means that voters have to spend additional time to process the option and differentiate it between all other options. When multiplied by the number of people who vote, that becomes a non-trivial waste of voter's time for options which couldn't find enough seconders who actually support the option. If an option can't get enough seconds from people who support that option to satisfy K (or even Q), not enough people support it for it to have a chance of being supported by a majority of people in an election that meets quorum. Don Armstrong 1: 102 subscriptions with @debian.org$ addresses, anyway. (For comparison, there are 147 subscribed to -devel, 112 to -project, and 324 to d-d-a.) I've no clue about actual DD readership or whether people actually read it or /dev/null it. Maybe they use it in place of almanacs in their out buildings. -- Three little words. (In descending order of importance.) I love you -- hugh macleod http://www.gapingvoid.com/graphics/batch35.php http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Tue, 30 Dec 2008, Wouter Verhelst wrote: On Mon, Dec 29, 2008 at 04:18:02PM -0800, Don Armstrong wrote: 1: I'd be happier, though, if those proposing and seconding options would be more careful about the effects that their options may have, and be more vigilant about withdrawing options when more palletable options exist. You should not be proposing or seconding an option that you don't plan on ranking first. Anthony Towns seconded his own recall vote, as DPL. Do you think he should not have done that? He voted 21 (FD over recall), so no. Of coure, that option had more than 5 othere seconds, each of whom voted 12, so it didn't do anything to cause us to vote on an option that we wouldn't of had a need to vote on otherwise. Since 48 people voted 12, the K (or Q, 1.5Q or 2Q) seconds could have easily come from them. I seconded both proposal B and proposal D on 2004_004, and did not rank both equally at number one (rather, I voted proposal B at 1, and proposal D at 2). Do you think I should not have done that? That's fine, since you ranked them both highly. There's a benefit to seconding options which represent compromises that you support. There's no benefit to seconding options which you do not, just to see them go down in flames in the election. [If an option cannot get the required number of seconders from people who actually support it, it's almost assuredly going down in flames in the election.] In general, I believe it is okay to second a ballot option that you do not plan to rank first if you feel it is an important matter that you want to see resolved. The statement I second this proposal only means I want to see this voted on, not I support this statement, and I think that's a good thing. I disagree. We shouldn't be having votes or options on the ballot purely for the sake of having votes or options on the ballot. Our voting process exists to resolve conflicts in a manner that DDs support; having options that DDs do not support on the ballot does not help that process. I view seconding as a trial run for a particular option involving a smaller number of people who vouch their support for that option so that the entire project does not have to be involved in dealing with options that do not have wide enough support to even have a chance of winning. Making the seconding process more difficult by increasing the number of seconds and trying to avoid seconding options that we ourselves do not support will help keep the project at large from wasting time reading and understanding ballot options that are not widely supported. Don Armstrong -- There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Bach http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Tue, 30 Dec 2008, Joerg Jaspert wrote: Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] Whatever we decide to do should specifically modify the constitution; that is a) §4.2.1 is replaced with The Developers follow the Standard Resolution Procedure, below. A resolution or amendment is introduced if proposed by any Developer and sponsored by at least floor(2Q) other Developers, or if proposed by the Project Leader or the Technical Committee. b) §4.2.2.2 is replaced with If such a resolution is sponsored by at least floor(Q) Developers, or if it is proposed by the Technical Committee, the resolution puts the decision immediately on hold (provided that resolution itself says so). etc. I'd also suggest alternatively, that we change K to be floor(Q), and modify §4.2.1 to be 2K, §4.2.2.2 to be K, and §4.2.2.3 to be left alone, which would have the same effect, but with fewer changes (and we could define floor(Q) instead of assuming it to be known.) Because quorum is 3Q, this would mean that any option will have enough voters to conceivably win in an election. [I would also be ok with K==1.5Q, and requiring at least K developers for each step.] All that said, I'd be interested in seeing such a change made.[1] Don Armstrong 1: I'd be happier, though, if those proposing and seconding options would be more careful about the effects that their options may have, and be more vigilant about withdrawing options when more palletable options exist. You should not be proposing or seconding an option that you don't plan on ranking first. -- This message brought to you by weapons of mass destruction related program activities, and the letter G. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
[switching to -vote only, since this is about the process of voting] On Tue, 30 Dec 2008, Ben Finney wrote: This seems quite wrong. Why should one not carefully and precisely phrase and propose an option that one does *not* agree with, in order to get it voted on? Because it can potentially lead to a waste of everyone's time. One of the major reasons why we require proposals and seconds is to limit the options proposed to ones that a significant proportion of Developers actually agree with and plan on voting for. That's not to say that you shouldn't offer suggestions for improvements in options that you don't agree with; you just shouldn't propose or second them. [If it's popular enough to be a useful option, the people with whom the option is popular will propose and second; it's not like it's hard to do.] Don Armstrong -- If you have the slightest bit of intellectual integrity you cannot support the government. -- anonymous http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
On Tue, 23 Dec 2008, Steve Langasek wrote: Having two sets of images doesn't make sense to me; the CD team have already posted publically this cycle about the infrastructure challenges involved with publishing those images that they already have to accomodate, doubling the image count doesn't sound feasible, IMHO. I don't see the need for multiple CD sets.[1] All that should be needed is a single first CD (netinst or similar small image?) and hdimage (and floppies?) with all of the non-free firmware we can legally distribute present.[2] After the initial installation, users can then use the normal CDs and or DVDs to add additional software. Presumably the non-free firmware CD would also contain the packages and archive structure necessary for normal installation of the non-free firmware containing packages. I'd think that an extra 600Mx3 (or however many architectures need non-free firmware) wouldn't be a huge deal for our cdimage mirrors. Ideally, such a CD would be marked as unofficial or similar to indicate that it contains non-free firmware, but it could be linked and distributed as normal. Don Armstrong 1: -vote really is the wrong list to discuss this on; Cc'ing debian-cd so knowledgeable people there can tell me I'm on crack. 2: We could make the larger images too, I guess, but there's no reason why you couldn't just load the packages from the normal set of media. -- Americans can always be counted on to do the right thing, after they have exhausted all other possibilities. -- W. Churchill http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Thu, 18 Dec 2008, Raphael Hertzog wrote: On Wed, 17 Dec 2008, Manoj Srivastava wrote: On Tue, Dec 16 2008, Richard Hartmann wrote: I think he had the implied accussation from the GR's text in mind. Option 1 is to 'Reaffirm the Social Contract', which means that dissenting votes weaken and/or break the SC. No idea if that is on purpose or a honest mistake, but I am assuming good faith with Manoj as with everyone else. The title for ballot lines are proposed by the proposer when titling their proposals. Ask the proposer. Stop this. “It's not me, it's the proposer” is childish. It's not too difficult to see whether a summary is fair or not. It's not too difficult to acknowledge the problem when others have pointed it out. Considering the sheer level of vitriol and claims of malfeance directed at the Secretary, it's no wonder the Secretary has decided to utilize the title proposed by the proposer and defer to the proposer in matters of the ballot title. Furthermore, we're talking about a *TITLE* here, not a *SUMMARY*. There's no way that four words can possibly summarize a 111 word proposal. Have you ever tried to reach consensus in you secretarial work instead of doing only what you feel like doing? The ballot was and its options were made public with a chance for everyone to review and make comments well before the vote. You made comments, and in 874p1a6l0n@anzu.internal.golden-gryphon.com were instructed to get the approval of the proposer of the option in order for the secretary to change the title of the option. FWICT, you either did not attempt to do so, or none of the people who proposed or seconded the proposal agreed with your suggested change. That's of course your option, but berating the Secretary for failing to try to reach consensus when you haven't either after having been asked to do so seems disingenuous. Finally, I would seriously hope that anyone who has voting rights in Debian is fully capable of completely ignoring the title of the ballot option and actually reading the text of the issue under discussion, as no ballot title can possibly convey the entirety of the issue under discussion nor the portions of the issue that are of most significant to each voter. I know I do due dilligence before voting; if anyone can't for whatever reason, vote a blank ballot. Don Armstrong -- To punish me for my contempt of authority, Fate has made me an authority myself -- Albert Einstein http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: For our own good: splitting the vote. Thoughts?
On Wed, 12 Nov 2008, Adeodato Simó wrote: I hate complex ballots. They tend to work against the goal of a vote, which is getting a crystal clear assessment on the opinions of the Developers. The goal of a vote is the ranking of options; this doesn't necessarily coincide with a clear assessment of the opinions of the population. Furthermore, splitting non-disjoint options into separate votes has a myriad of other problems that Manoj has identified. I also think throwing amendments is a too cheap operation nowadays. The procedure for amendments isn't any less cheaper than the procedure for submitting a GR itself. People seconding and/or submitting proposals/amendments should only do so for amendments that they support, and should withdraw their proposal or second for amendments which they no longer support. Don Armstrong -- THERE IS NO GRAVITY THE WORLD SUCKS -- Vietnam War Penguin Lighter http://gallery.donarmstrong.com/clippings/vietnam_there_is_no_gravity.jpg http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Mon, 31 Mar 2008, Joey Hess wrote: By bringing an issue to the tech ctte, both sides of the issue have to give up some control, and thus reposibility. So in this case it's not just wordpresses's maintenance, but also the security support work that the security team would notmally handle (ie, writing DSAs and pushing out fixes) that the tech ctte delegate would be responsible for. I agree that the stable security team should no longer be responsible for the wordpress package,[1] but when the maintainer (who's responsibility it is anyway) has stepped up and said that they were going to maintain the packages through a full stable release cycle, then they have the responsibility to do so. If that breaks down, members voting for the referrendum should exercise responsibility instead. I just disagree with the idea that a TC decision automatically obsolves all parties (save the TC) to the decision of their responsibilities. FWIW, at least these security holes seem pretty bad: CVE-2007-3543, CVE-2007-3544 remote upload and execution of php code CVE-2007-4154 7 varieties of SQL injection CVE-2008-0196 directory traversal via .., and arbitrary file modification CVE-2007-1599, CVE-2007-3639 redirect authenticated users to other sites and obtain potentially sensative information Yuck. On Mon, 31 Mar 2008, Moritz Muehlenhoff wrote: Don Armstrong wrote: The package in question, as problematic as it is, has an active maintainer who claimed that he would do exactly this. People claim stuff all the time. It's also Neil McGovern who promised to do it and never did so. (Which is especially bad since at least two people quoted this to be a reason to keep it in their vote) It's not clear to me what sort of guarantee you would require; at some point it all comes down to people and their commitments. People who serve on the CTTE as well as people in general can always renege their commitments. They shouldn't do so, but it happens anyway. Don Armstrong 1: Though I must admit that it's not clear to me why http://packages.qa.debian.org/w/wordpress/news/20080306T195216Z.html hasn't been accepted. -- A citizen of America will cross the ocean to fight for democracy, but won't cross the street to vote in a national election. -- Bill Vaughan http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Tue, 01 Apr 2008, Thijs Kinkhorst wrote: On Tuesday 1 April 2008 00:18, Don Armstrong wrote: I agree that the stable security team should no longer be responsible for the wordpress package,[1] [...] 1: Though I must admit that it's not clear to me why http://packages.qa.debian.org/w/wordpress/news/20080306T195216Z.html hasn't been accepted. Huh? The subject of that mail starts with Accepted. Those mails get triggered if stuff is accepted. See also: Arg. Apparently I'm totally not paying attention here. Don Armstrong -- Because, Fee-5 explained patiently, I was born in the fifth row. Any fool would understand that, but against stupidity the very Gods themselves contend in vain. -- Alfred Bester _The Computer Connection_ p19 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Sat, 29 Mar 2008, Joey Hess wrote: Well, just to pick an example, if the TC had chosen you to deal with the wordpress-in-stable issue, and you had personally decided it needed to be in stable, and had done whatever work was initially needed to get it into stable with security support, you'd still be responsible for its security now, and the several security holes it has now would be a problem that you'd be aware of, and at least be worrying about if nothing else. The package in question, as problematic as it is, has an active maintainer who claimed that he would do exactly this. According to the list of open bugs that I can see, the security issues that are currently affecting the stable version are supposedly minor. [If they're not, someone who knows more about the CVEs in question that I do should file more bugs and/or adjust severities appropriately.] Don Armstrong -- [A] theory is falsifiable [(and therefore scientific) only] if the class of its potential falsifiers is not empty. -- Sir Karl Popper _The Logic of Scientific Discovery_ §21 http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Q: All: Account creation latency
On Wed, 19 Mar 2008, Peter Palfrader wrote: I think the problem would be trivial to fix. The DAM should be the party that makes the *policy decision*, and then DSA should be tasked with actually creating the account, and keyring-maint with adding the key to the debian keyring. What is needed for this to become so? From where I sit, the solution seems clear: 1) Upon direction from DAM(s) DSA creates/deletes/deactivates accounts; all acccount activities are announced to -newmaint (or -private for non-public issues) 2) keyring-maint adds/removes identities to the keyring upon the direction of DAM; syncing with LDAP. Updates keys on own volition, with announcements to some appropriate location. (-newmaint?) I don't see any reason why both DSA and the keyring-maint should fail to deal with requests within a week or so unless they're on VAC.[1] As near as I can gather, it appears that so far no one feels to have the power necessary to change how account creation and key modification actually works. What do the DPL candidates feel about this? Do we require a GR to direct how account creation and keyring management is to be handled? Don Armstrong 1: There's nothing bad about not having enough time to do a volunteer job, but failing to ask for help (or turning a task over to someone else) hurts us all. -- Democracy means simply the bludgeoning of the people by the people for the people. -- Oscar Wilde http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Technical committee resolution
On Tue, 11 Mar 2008, Anthony Towns wrote: And without both those things, even if it improves now, it will stagnate again in future. Since the problem is stagnation, what about trying to address that directly? I suggest assigning each open issue to a CTTE member in turn who acts as the chair for that issue (with skipping if the member should recuse themselves because they are directly involved.) [This can be tracked using the owner field in the BTS.] If an issue itself isn't put to a vote within a month or a week of the last message on the issue (whichever is longer), the person assigned to the issue is assumed to be inactive or too busy to serve, and is removed from the CTTE, and a new member is appointed in their place. The issue is assigned to the next unassigned member which resets the last message timer, and everything continues. The CTTE chair is responsible for the assignment of members to issues, and also acts as a issue chair in turn; the failure to assign a member to an issue within a suitable timeframe (one week?) is taken as inactivity as well, and the chair is removed, and an immediate vote taken to select a new one. The only question is for people who are validly on VAC, but presumably someone on VAC should arrange for an active CTTE member to handle issues while they are away. [The times above are just first stabs; I'm not attached to them by any means.] Don Armstrong -- Mozart tells us what it's like to be human, Beethoven tells us what it's like to be Beethoven, and Bach tells us what it's like to be the universe. -- Douglas Adams http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DPL Debate [Re: Debian Project Leader Election 2008]
On Tue, 19 Feb 2008, Manoj Srivastava wrote: Also, people who are willing to conduct the annual Debates will have less time to coordinate and plan, since the nomination period has been shortened, and the debate would need to be held in the later part of march. I'll volunteer to coordinate the debates again if that's acceptable to everyone. [If not, ignore the rest of this message. ;-)] I imagine that we'll end up having a debate some time beteween 3/21 and 3/30, so candidates should start to figure out when in those times they'll be available. Additional people to help select questions, prod the discussion channels, and otherwise actually make things happen are needed too. Also, any suggestions on changes to the format to make things more useful for the voters are appreciated. You can remind yourself of the format used last year here: http://svn.donarmstrong.com/don/trunk/projects/debian/dpl_debates/debate_rules_public.txt Don Armstrong -- She was alot like starbucks. IE, generic and expensive. -- hugh macleod http://www.gapingvoid.com/Moveable_Type/archives/001376.html http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Supermajority requirement off-by-one error, and TC chairmanship
On Fri, 15 Feb 2008, Bas Wijnen wrote: Because of the error you're making. With 6 people, 2/3 of the votes is 4 votes, with no error. more than 2/3 needs 5 votes, or 5/6th. So even though the stated requirement is more than 2/3, the actual requirement is at least 5/6th. The difference is 1/6th of the votes, or 16 2/3%. In other words, due to the small sample, the requirement is more than 16% higher than intended. With 6 people, 1/2 of the votes is 3 votes, with no error. more than 1/2 needs 4 votes, or 4/6th. So even though the stated requirement is more than 1/2, the actual requirement is at least 4/6th. The difference is 1/6th of the votes, or 16 2/3%. In other words, due to the small sample, the requirement is more than 16% higher than intended. [Wonderous how the numbers work out exactly the same.] Don Armstrong -- We have to face the fact that either all of us are going to die together or we are going to learn to live together and if we are to live together we have to talk. -- Eleanor Roosevelt http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Constitutional amendment: reduce the length of DPL election process
On Sat, 11 Aug 2007, Wouter Verhelst wrote: Here's a reason: to reduce the period during which there is uncertainty about the DPL's powers. There's really no uncertainty about them, though. The outgoing DPL is still in power until the post becomes vacant at the end of the term. During elections, it's hard for an incumbent DPL to use his powers, for fear of stuff like http://lists.debian.org/debian-vote/2007/02/msg00162.html happening. Reactions to doing your job during the entirely of your term are just going to happen, some well thought out, some merely gut responses. [That particular message isn't such a good example though, because it's a reaction to something which was done which isn't a power of the DPL by someone who was not the DPL.] Right after the election (or vote, if you please), if the DPL-elect is not the incumbent DPL and was elected on a platform that is sufficiently different from the incumbent DPL's platform and/or conduct as DPL, then having the incumbent DPL stay in office for too long is questionable. I'm of the opinion that three weeks to bring all currently open projects to a position where they can be smoothly transfered to the DPL-elect is desirable. The election period does not end when the vote ends, and so your amendment defeats the whole purpose of aj's proposal. The election period does end, though. Only a transition period is added in which can be used as a buffer zone in case the nomination period and/or voting period needs to be extended. Don Armstrong -- If you find it impossible to believe that the universe didn't have a creator, why don't you find it impossible that your creator didn't have one either? -- Anonymous Coward http://slashdot.org/comments.pl?sid=167556cid=13970629 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to: reduce the length of DPL election process
On Wed, 08 Aug 2007, MJ Ray wrote: The organisers and most time slot limitations could be identified before nominations close and the possibilities announced. The organisers were already being identified before nominations closed this year, after all:- The problem is really that figuring out a slot which will work for all individuals concerned is non-trivial, and depends on finding out the exact set of people involved. Organisers sought 15 Feb 2007 http://lists.debian.org/debian-vote/2007/02/msg00150.html Nominations closed 25 Feb 2007 http://www.debian.org/vote/2007/vote_001 Asking before nominations open probably would get a more neutral panel than now. Candidates could be asked times as soon as they are nominated, with a preference for an early debate. It's not been my practice to discriminate in accepting people for the panel; so it should be as neutral as possible. [Whoever is the moderator is always going to be biased, but I don't think there's any way to get around that.] The time this year was decided about 5 days after nominations closed:- Announced 2 Mar 2007 http://lists.debian.org/debian-vote/2007/03/msg00023.html Right; I imposed a time limitation on the responses from the candidates to the debate schedule, and a rapid last call to the scheduled time. I don't think that time can be cut down very much unless the organizers were to send the fast moving black objects[1] after the candidates. While we're shortening the election, maybe the debate could be cut down from three hours, if it would make it simpler to organise. That would also reduce the amount of material generated for voters to read. The actual time that the debate takes isn't particularly troublesome from an organizational standpoint, and if it becomes the case that we can't fit a 3 hour (or whatever length the organizers decide on) debate into the schedule of candiates, it can be abridged appropriately. The main issue from where I sit is allowing enough time for nominees to post position statements and to have enough time for those position statements digested by the electorate, and enough initial discussion to occur so that interesting questions can be found for the debate. If candidates don't have these ready at the beginning of the campaign period, then the quality of the debate (and discussion) suffers. Don Armstrong 1: TINCAITIIDNOH -- Information wants to be free to kill again. -- Red Robot http://www.dieselsweeties.com/archive.php?s=1372 http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Constitutional amendment: reduce the length of DPL election process
On Tue, 31 Jul 2007, Anthony Towns wrote:
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
Is there any reason to reduce this time period? Having a buffer zone
of three weeks is useful for continuity and/or cases where the
nomination period must be extended (though it leads to a short lame
duck period).
Don Armstrong
--
When bad men combine, the good must associate; else they will fall one
by one, an unpitied sacrifice in a contemptible struggle.
-- Edmund Burke Thoughts on the Cause of Present Discoontents
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On the Debian Maintainers GR
On Thu, 26 Jul 2007, Julien BLACHE wrote: Raphael Hertzog [EMAIL PROTECTED] wrote: Reading d-d-a isn't enough to keep up with everything that's happening in the Project, and you know it. But if it's enough for DD, it should be enough for DM. We have many DD who It's *not* enough for DDs. I agree as well, but it's all that we require DDs to subscribe to. [That said, we really should work to make d-d-a enough; decisions that and transitions that affect multiple packages should be announced there.] Frankly, there's nothing stoping us from recommending/requiring DMs to be active/subscribed to other lists too; we just have to do it. Don Armstrong -- Nothing is as inevitable as a mistake whose time has come. -- Tussman's Law http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On the Debian Maintainers GR
On Thu, 26 Jul 2007, Steve Langasek wrote: On Thu, Jul 26, 2007 at 11:00:14PM -0700, Don Armstrong wrote: I agree as well, but it's all that we require DDs to subscribe to. [That said, we really should work to make d-d-a enough; decisions that and transitions that affect multiple packages should be announced there.] Frankly, there's nothing stoping us from recommending/requiring DMs to be active/subscribed to other lists too; we just have to do it. If you announce too many transitions there that aren't relevant to the vast majority of maintainers, those maintainers will stop paying attention to d-d-a. IMHO most transitions should be coordinated privately among the affected developers, as is generally the case today. Right; I guess I really meant that information on transitions that wasn't directly communicated to affected maintainers. Don Armstrong -- Information wants to be free to kill again. -- Red Robot http://www.dieselsweeties.com/archive.php?s=1372 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Limited upload rights for NMs GR Proposal
On Tue, 10 Jul 2007, Pierre Habouzit wrote: On Mon, Jul 09, 2007 at 08:33:20PM +0200, Bastian Venthur wrote: * confirmed that the New Maintainer successfully passed the ID-, TS- and PP check I think this is the wrong time. My opinion of current TS is that it's completely on crack, I mean, okay, if one is going to package a library, he will have to learn what it means. But how many people are indeed packaging libraries ? Not _that_ many. I won't never ever touch a perl package, and am unlikely to package a ruby extension. The TS section's format is entirely up to the AM; lots of AMs use the current TS format because it's easier for them and it at least makes sure that the NM knows where to find the answers to the questions that are asked and is reasonably aware of the issues entailed therein. A regular work of his NM, watched carefully, is a better TS that what is done right now. While I can't speak for all AMs, I track what my applicants have done before I recommend them to become DDs; TS is just one tool that I use. Finally, the ability of maintainers to upload their own packages without being a DD isn't an attempt to improve the NM process; it's an attempt to allow people to contribute who may not actually want to become DDs. Under Antony's proposal, NMs can become DMs at any point that their AM feels they are ready, be that after TS, or PP or whenever. Don Armstrong -- Junkies were all knitted together in a loose global macrame, the intercontinental freemasonry of narcotics. -- Bruce Sterling, _Holy Fire_ p257 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: GR to deal with effects of a personal dispute
On Thu, 31 May 2007, Brian May wrote: Is it possible to act as a developer without mailing list access? Yes, just as it's possible to act as a developer if you've been excluded from using [EMAIL PROTECTED]; you just have to use an intermediate who can send on messages on your behalf. Don Armstrong -- Americans can always be counted on to do the right thing, after they have exhausted all other possibilities. -��� W. Churchill http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Question for Sam Hocevar xxx xxxxxx xxxxxxxxxxx xx xxxxxxx
On Sat, 05 May 2007, Craig Sanders wrote: if he wants to move on and grow up and put it behind him, let him. it's not like a stupid parody organisation actually harms anyone or anything. Except that most parody organizations don't have a long history of attacking Debian-associated IRC channels and operators within them, coupled with anti-feminism/anti-semitic/anti-homosexual rhetoric. Regardless, I'm personally more concerned by the appearance that people who asked this question of Sam before voting were lied to than the nature of a ill-conceived group of trolls. I don't know if Mathew Garrett's allegations are true or not, but their implications for the trustworthiness of our DPL if true are troubling. Don Armstrong -- No amount of force can control a free man, a man whose mind is free [...] You can't conquer a free man; the most you can do is kill him. -- Robert Heinlein _Revolt in 2010_ p54 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
On Fri, 20 Apr 2007, Ben Finney wrote: Don Armstrong [EMAIL PROTECTED] writes: On Thu, 19 Apr 2007, Nathanael Nerode wrote: How about: There is a special exception for the texts of the licenses under which works in Debian are distributed; It's not just enough for that; it has to be a license specifically being used as a license under which a work in Debian is being distributed. [IE, in debian/copyright or specifically included by reference from there.] For example, a second copy of the GPL in a package under the GPL would not be acceptable, nor would a copy of the GPL in a package not under the GPL. I presume the distinction you're making there is between license texts that are already distributed in /usr/share/common-licenses/ and license texts that aren't. I'm not making such a distinction. The actual location in which the license is distributed does not matter. All that matters is that it is a license being used as a legal document under which a work in Debian is being distributed. It cannot be a license whose removal or abridgement would have no legal effect upon the work in which it is distributed. [I would argue as well that its removal cannot have a functional effect on the work either.] Don Armstrong -- What I can't stand is the feeling that my brain is leaving me for someone more interesting. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
On Thu, 19 Apr 2007, Nathanael Nerode wrote: How about: There is a special exception for the texts of the licenses under which works in Debian are distributed; It's not just enough for that; it has to be a license specifically being used as a license under which a work in Debian is being distributed. [IE, in debian/copyright or specifically included by reference from there.] For example, a second copy of the GPL in a package under the GPL would not be acceptable, nor would a copy of the GPL in a package not under the GPL. Don Armstrong -- An elephant: A mouse built to government specifications. -- Robert Heinlein _Time Enough For Love_ p244 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
On Thu, 19 Apr 2007, Ben Finney wrote: This doesn't address the concern that motivated this discussion: that the license texts which have restrictions on modification are non-free works by the DFSG, yet are being distributed in Debian against the Social Contract. License texts which are being distributed in their capacity as a license under which a work in Debian is distributed cannot be modified necessarily. I don't believe anyone is seriously arguing differently, save as a method of defending non-modifiability elsewhere. This was raised in 2004 on this list (and presumably earlier as well.)[1] I don't believe we need an amendment to the Social Contract to specifically state this as the case, but a correctly worded one which specifically amended the social contract and/or the DFSG appropriately may be worth some thought. Unfortunatly, the currently proposed amendment does not disambiguate between license texts in their capacity as a license under which a work is distribute and random text which is labelled as a license. Don Armstrong 1: http://lists.debian.org/debian-vote/2004/01/msg01307.html -- All bad precedents began as justifiable measures. -- Gaius Julius Caesar in The Conspiracy of Catiline by Sallust http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Project Leader Elections 2007: Draft ballot
On Fri, 16 Mar 2007, Ian Jackson wrote: Could it be permitted rearrange the entries on the ballot ? It would be much clearer to be able to vote: [ 1 ] Choice B: Bob [ 2 ] Choice A: Alice [ 3 ] Choice Z: None Of The Above [ 4 ] Choice C: Carol It's not clear to me how you'd express ranking options equally. Don Armstrong -- S: Make me a sandwich B: What? Make it yourself. S: sudo make me a sandwich B: Okay. -- xkcd http://xkcd.com/c149.html http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DPL Debate in #debian-dpl-debate on irc.debian.org in ~12 hours (21:30 UTC)
This is just a quick reminder that the DPL Debate will happen in #debian-dpl-debate on irc.debian.org in approximately 12 hours (21:30 UTC). Discussion will happen in #debian-dpl-discuss. Also, if you have questions that you'd like to have asked during the debate, please feel free to e-mail them to me (the sooner the better). See http://svn.donarmstrong.com/don/trunk/projects/debian/dpl_debates/debate_rules_public.txt or the previous announcement if you want more information. Don Armstrong -- NASCAR is a Yankee conspiracy to keep you all placated so the South won't rise again. -- http://www.questionablecontent.net/view.php?comic=327 http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
DPL Debate at 21:30 UTC on March 10th, 2007 [#debian-dpl-debate on OFTC]
Don't forget, the DPL Debate will be on IRC in #debian-dpl-debate on irc.debian.org (OFTC) at 21:30 UTC, March 10th 2007, ending at 00:30 UTC, March 11th 2007. Discussion of the debate will occur in #debian-dpl-discuss on the same network. The executive summary: Start at 21:30 UTC 0. Introductions 1. Drafted Responses to questions (6 minutes per, 5-7 questions) -- 5 minute break -- 2. Moderated Debate (1.5 min/5 line responses, one candidate at a time) -- 5 minute break -- 3. Free For All (30-45 minutes of no holds barred slugfest) -- 8 minute break -- 4. Closing Statements Stop at 00:30 UTC A call for panelists: MJ Ray (slef), David Nusinow (gravity), Neil McGovern (Maulkin), Mohammed Adnène Trojette (adn), Pete Nuttall (psn) have volunteered to assist me (dondelelcaro) to select questions for the debate from the audience and the mailing lists. The Rules: This years debate will again be split into three separate sections in an attempt to get an idea of what each candidate's own opinions are off the cuff while avoiding unnecessarily penalizing non-native English speakers. First off, the ground rules for all sections: We will start the debate as soon as all candidates are present, or no later than 21:45 UTC. Each section will last approximately 30-45 minutes, with a 5 minute break in between sections. We will stop the debate and devoice all of the candidates no later than 00:30 UTC, with closing statements to be pasted starting no later than 00:40 UTC. Additional debate and discussion may occur in #debian-dpl-discuss. The first section will consist of a series of questions (5-7) which will be posed to the candidates all at once. Candidates will have 6 minutes to draft a response to each question. I will warn candidates when the six minutes are almost up, and will allow one late response from each candidate; additional late responses will not be sent to the debate channel. The candidates will be told the next question immediately following the close of responses for the previous question; the audience will be told the next question as soon as the responses have finished pasting. There will be a 5 minute break. The second section is a more controlled approach of the free for all that we had after the response part above last year. There will be a series of questions, and candidates will be able to respond by writing lines directly to the channel. In order to respond, candidates must first be publicly recognized by the moderator. Candidates will request to be recognized by using an out-of-band channel to avoid cluttering -debate. Everyone will have 1.5 minutes to respond or 5 messages, whichever is lesser, after they have been recognized. The moderator will also entertain rebuttals. Rebuttals will happen in exactly the same manner as above; candidates will be recognized, and they'll have 1.5 minutes or 5 messages to respond, whichever is lesser. The questions may be directed at a specific candidate (in the case of clarification or response questions), or at all candidates. The moderator (with the assistance of the panelists) will attempt to even out the questions and rebuttals granted between the candidates to the extent possible. To avoid having the fastest people always speaking first, the moderator will attempt to randomize the order in which candidates are recognized. However, the moderator will start recognizing people at most 15 seconds after the question has been asked, just to keep things moving. Throughout this section, the moderator will attempt to avoid using technical measures to control the candidate's ability to speak. If the moderator has recognized someone, only they can speak after they have been recognized. The moderator will warn each candidate once if speaking out of turn happens; the second time the moderator will begin voicing and devoicing. There will be a final 5 minute break. The third and final section will be an absolute and total free for all. The moderator will attempt to ask questions and followup questions from the audience and get the candidates to all engage each other.It is suspected that multiple conversations will begin to occur at once, and multiple questions will be being asked at once in a massive bout of chaos. It'll be great fun. After about 30-40 minutes of chaos, the debate will come to a close. Candidates will have 8 minutes to compose closing statements if they desire, during which the moderator will make closing statements. The closing statements will be pasted to the IRC channel starting no later than 00:40 UTC. Logs from all of the channels involved will be made publicly available after the debate for reference by voters and other interested individuals. Don Armstrong -- This can't be happening to me. I've got tenure. -- James Hynes _Publish and Perish_ http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
DPL Debate on March 10th, 2007 at 21:30 UTC
Barring any serious last minute objections[1] the DPL Debate will be held in #debian-dpl-debate on irc.debian.org (OFTC) at 21:30 UTC on Saturday March 10th, 2007, ending around 00:30 UTC on the 11th. I'll be making an announcement shortly to -announce reiterating the debate rules. Don Armstrong 1: I've already sent this to the candidates, but who knows? ;-) -- If you find it impossible to believe that the universe didn't have a creator, why don't you find it impossible that your creator didn't have one either? -- Anonymous Coward http://slashdot.org/comments.pl?sid=167556cid=13970629 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DPL Debate Scheduling [Re: DPL Debate Volunteers and Format]
On Sat, 24 Feb 2007, Don Armstrong wrote: I'd like to make a decision on the time for the debate within the next few days, so if you have serious objections to either method, you need to make them known. Most of the candidates have responded to my requests for scheduling information, but: Gustavo Franco [EMAIL PROTECTED] Sven Luther [EMAIL PROTECTED] Steve McIntyre [EMAIL PROTECTED] Simon Richter [EMAIL PROTECTED] still have not. In the off chance that they're not reading their Debian mailboxes, I'm sending this to -vote. The current scheduling information is here: http://svn.donarmstrong.com/don/trunk/projects/debian/dpl_debates/debate_schedule.gnumeric and if I don't hear differently in the next 24 hours, I'll assume that I have free reign to schedule the debate at any free time within that schedule. Don Armstrong -- All bad precedents began as justifiable measures. -- Gaius Julius Caesar in The Conspiracy of Catiline by Sallust http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DPL Debate Scheduling [Re: DPL Debate Volunteers and Format]
On Tue, 27 Feb 2007, Julien Cristau wrote: On Mon, Feb 26, 2007 at 18:03:19 -0800, Don Armstrong wrote: Most of the candidates have responded to my requests for scheduling information, but: Sven Luther [EMAIL PROTECTED] I guess this should be [EMAIL PROTECTED]? Err, yes... I sent it to the proper address the second time. Don Armstrong -- She was alot like starbucks. IE, generic and expensive. -- hugh macleod http://www.gapingvoid.com/batch3.htm http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DPL Debate Volunteers and Format
On Thu, 15 Feb 2007, Don Armstrong wrote: If you wish to volunteer, please e-mail me or contact me on IRC (I'm dondelelcaro). So far (hopefully I haven't missed anyone) the volunteers I have are: Neil McGovern (Maulkin) David Nusinow (gravity) Pete Nuttall (psn) MJ Ray (slef) Mohammed Adnène Trojette (adn) [If I've missed you, please respond to let me know.] Also, if any of you have comments about the format of the debate now would be an appropriate time to raise them. http://svn.donarmstrong.com/don/trunk/projects/debian/dpl_debates/debate_rules_public.txt are the rules that we used last year, but they are (of course) totally open to revision. To date no one has really commented on the rules for the debate, so I'll assume that the proposed format is acceptable unless someone coments. The next small issue as far as format goes is the number of candidates this year. I'm not sure how well a 9 candidate debate will work, and a suggestion was made to hold two separate debates. I'm open to do either even though the second means more work for me, but I don't want to unecessarily segregate candidates if that can be avoided. I'd like to make a decision on the time for the debate within the next few days, so if you have serious objections to either method, you need to make them known. Don Armstrong -- Quite the contrary; they *love* collateral damage. If they can make you miserable enough, maybe you'll stop using email entirely. Once enough people do that, then there'll be no legitimate reason left for anyone to run an SMTP server, and the spam problem will be solved. -- Craig Dickson in [EMAIL PROTECTED] http://www.donarmstrong.com http://rzlab.ucr.edu
DPL Debate Volunteers and Format
I'd like to reiterate the solicitation for volunteers to help run the DPL Debate: I need at least two other people who would be willing to volunteer to help me both in the organization of the debate (selection of initial questions, format suggestions, etc.) and the actual running of the debate (selecting questions from the audience, dealing with the -discuss channel, etc.) If you wish to volunteer, please e-mail me or contact me on IRC (I'm dondelelcaro). Also, if any of you have comments about the format of the debate now would be an appropriate time to raise them. http://svn.donarmstrong.com/don/trunk/projects/debian/dpl_debates/debate_rules_public.txt are the rules that we used last year, but they are (of course) totally open to revision. [The date and times will of course change depending on the candidates availability.] Don Armstrong -- We were at a chinese resturant. He was yelling at the waitress because there was a typo in his fortune cookie. -- hugh macleod http://www.gapingvoid.com/batch31.php http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New General resolution proposed
[Please respond back to -vote where this belongs, not here.] On Mon, 12 Feb 2007, Joe Buck wrote: Right now, those who run auto-builders are trusted, but the GR proposes to trust all developers. Right? It doesn't really change anything because nothing stops you as a developer from uploading binary packages which do not correspond to the source which you have uploaded. Don Armstrong -- Where I sleep at night, is this important compared to what I read during the day? What do you think defines me? Where I slept or what I did all day? -- Thomas Van Orden of Van Orden v. Perry http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation
[Stripping out the cross posting since it's annoying] On Fri, 27 Oct 2006, Sven Luther wrote: On Thu, Oct 26, 2006 at 06:10:46PM -0500, Debian Project Secretary wrote: | 4. If the decision is put on hold, an immediate vote is held to |determine whether the decision will stand until the full vote |on the decision is made or whether the implementation of the |original decision will be delayed until then. There is no |quorum for this immediate procedural vote. You are overpassing your rights as secretary, it is not for you as secretary to call for a vote, or take any such actions, but it is only the proposer and the seconders who can do such. What part of immediate vote isn't clear? All this does is determine whether the decision of the DPL is put on hold or stands for the course of the discussion/resolution period. Even if Manoj were to delegate the running of this vote to another developer,[1] that developer would have to conduct an immediate vote as well. Don Armstrong 1: I don't see an issue with suggesting this just to avoid any possibility of this kind of accusation, but it's not like running the vote has any special power in this regards; everything is pretty well spelled out by the constitution. [This is why jurists recuse themselves, of course... not that they aren't capable of being even handed, but just to preserve the appearance of the same.] -- I don't care how poor and inefficient a little country is; they like to run their own business. I know men that would make my wife a better husband than I am; but, darn it, I'm not going to give her to 'em. -- The Best of Will Rogers http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation
On Fri, 27 Oct 2006, Anthony Towns wrote:
I can't see anywhere in the resolution it claims to invoke 4.2.2.2,
so afaics that doesn't apply.
Since the resolution itself is about putting a decision on hold, 4.2
seems to apply; the resolution must say so verbiage seems to be
there to avoid putting a decision on hold by an amended resolution
seconded by 2K developers which affirms a decision. [Although, the
alternative supposition is tenable, even if it differs from my initial
reading. Clarification by the proposer would resolve this issue.]
I should note as well that 4.2.5 conflicts slightly with the current
powers granted under 4.1.{3,4} to developers... but that's not all
that big of a deal.
I'm not sure what all this is aiming to achieve beyond being a
different attempt to effectively prevent me from exercising any DPL
powers, and to further discourage people from having any faith in
our constitutional processes.
This part of the process is there to make sure that what those in
vested positions in Debian do don't overstep the bounds set by the
larger project; being able to overrule any constitutional delegate is
an important part of the constitutional process, as hurtful as it may
be to those who are threatened with being overruled.
In any event, it'd be nice to just resolve the after effects if that's
even possible, as it seems that the initial cause of this current
fracas was just heated discussion, the feared consequences of which
have failed to materialize at all.
Don Armstrong
--
In all matters of government, the correct answer is usually: Do
nothing
-- Robert Heinlein _Time Enough For Love_ p428
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Wed, 18 Oct 2006, Anthony Towns wrote: On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote: The answer to the question in the subject is simple: NO. Thankyou for your opinion. I note you seemed to neglect to mention that you're not a lawyer. That should be abundantly apparent to anyone who has been paying attention. Regardless, it doesn't dismiss the crux of the argument: baring competent legal advice to the contrary,[1] distributing sourceless GPLed works is not clear of legal liability. Doing otherwise may put ourselves and our mirror operators in peril. Don Armstrong 1: And frankly, I'd be suspicious of the source of any legal advice claiming that violating the letter of the GPL was something that could be done without any concern for liability. -- I now know how retro SCOs OSes are. Riotous, riotous stuff. How they had the ya-yas to declare Linux an infant OS in need of their IP is beyond me. Upcoming features? PAM. files larger than 2 gigs. NFS over TCP. The 80's called, they want their features back. -- Compactable Dave http://www3.sympatico.ca/dcarpeneto/sco.html http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Sun, 15 Oct 2006, Sven Luther wrote: Well, we all know it is sourceless GPLed firmware, and we chose just to say the contrary, because it is convenient to us. If we know[1] a work is a sourceless GPLed work, then we cannot distribute it *at* *all*. Doing otherwise is wholly inappropriate, GR or no GR, and opens up us and our mirror operators to a whole scope of liability that they should not be facing. Don Armstrong 1: We can argue about whether we actually know or suspect or feel, but once it's clear, there's no other choice. I'd personally argue to be on the cautious side unless a copyright holder tells us that we're distributing what they actually use the modify the work, but that's just because I want Debian to continue to exist even in the face of insane copyright holders. -- A people living under the perpetual menace of war and invasion is very easy to govern. It demands no social reforms. It does not haggle over expenditures on armaments and military equipment. It pays without discussion, it ruins itself, and that is an excellent thing for the syndicates of financiers and manufacturers for whom patriotic terrors are an abundant source of gain. -- Anatole France http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel
On Wed, 11 Oct 2006, Sven Luther wrote: On Sat, Oct 07, 2006 at 06:52:41PM -0500, Debian Project Secretary wrote: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- c2d43675-9efa-4809-a4aa-af042b62786e [ ] Choice 1: Release Etch even with kernel firmware issues Manoj, you have again overstepped your Secretarial position, by issuing a misleading title for the proposal you propose. When Frederik accepted the proposed amendment, Manoj was no longer the proposer. Furthermore, the title of a voting option on the ballot is perfectly meaningless. Attempts by the secretary to make them informative are appreciated, but any voter who actually pays any attention to them should be voting the null ballot, as they clearly haven't informed themselves appropriately. Finally, there's no reason to crosspost this stuff to multiple lists; complaints about the form of the ballot belong on -vote. Don Armstrong -- Il semble que la perfection soit atteinte non quand il n'y a plus rien a ajouter, mais quand il n'y a plus rien a retrancher. (Perfection is apparently not achieved when nothing more can be added, but when nothing else can be removed.) -- Antoine de Saint-Exupe'ry, Terres des Hommes http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about GR-2006-004
On Mon, 09 Oct 2006, Francesco Poli wrote: OK, but reaffirming the literal meaning of DFSG#2 now does not help a future discussion where the DFSG will hopefully be changed to unambiguously affect all works (both programmatic and non-programmatic). It doesn't help or hinder it; discussions about what changes to the DFSG should be made or the nature of future discussions about those changes are just totally out of its scope. (And in the latter case, totally out of the scope of any GR.) [If it's too difficult to separate considering what a text currently says versus considering what one wishes it said, there's not much I can do to help.] Don Armstrong -- The sheer ponderousness of the panel's opinion ... refutes its thesis far more convincingly than anything I might say. The panel's labored effort to smother the Second Amendment by sheer body weight has all the grace of a sumo wrestler trying to kill a rattlesnake by sitting on it--and is just as likely to succeed. -- Alex Kozinski in Silveira V Lockyer http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel
On Sat, 07 Oct 2006, Debian Project Secretary wrote: Please note that the voting period is abridged, you only have one week to vote on this. Just in case there was any question, I excercise the power delegated to me in [EMAIL PROTECTED] to officially abridge the voting period to one week, with adjustments to start and end times at the secretary's convenience. Don Armstrong -- She was alot like starbucks. IE, generic and expensive. -- hugh macleod http://www.gapingvoid.com/batch3.htm http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Question about GR-2006-004
On Sun, 08 Oct 2006, Francesco Poli wrote: it was my understanding that the present rules (clarified by the famous Editorial amendments GR-2004-003) imply that *all* works in main must comply with the DFSG (including #2). This is correct. In other words, TTBOMK, *all* works distributed in the Debian system (i.e. in main), be they programmatic or non-programmatic, *must* be distributed with the form that the copyright holder or upstream developer would actually use for modification; and such forms need to be distributed in the orig.tar.gz. This GR seems to relax the rules for non-programmatic works. Unfortunatly, it does not. DFSG §2 says: The program must include source code, and must allow distribution in source code as well as compiled form. It does not say The work must include source code. Thus, the proposal very carefully walks the line that the DFSG currently walks. Whether the DFSG should apply to all works (or just some work) is an open question, and one that I believe should be discussed at length. Don Armstrong -- An elephant: A mouse built to government specifications. -- Robert Heinlein _Time Enough For Love_ p244 http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Question about GR-2006-004
On Sun, 08 Oct 2006, Francesco Poli wrote: On Sat, 7 Oct 2006 23:04:21 -0700 Don Armstrong wrote: Thus, the proposal very carefully walks the line that the DFSG currently walks. Whether the DFSG should apply to all works (or just some work) is an open question, and one that I believe should be discussed at length. I'm not very happy that the GR reaffirms this interpretation of the scope of DFSG#2. I think that maybe it would be much more useful if the issue of sourceless non-programmatic works were kept out of GR-2006-004 (that is to say, if the text of the GR didn't have item B.). This part of the GR merely restates what is current practice, advancing a literal interpretation of what DFSG 2 clearly requires. While I think the availability of source even for non-programmatic works is important, the DFSG does not clearly and unambiguously require them. This is why the resolution strongly recommends them, but does not require them. What seems awkward to me is that there are other sentences in the DFSG that speak about programs, rather than works. Sure; the DFSG is unfortunatly worded rather inelegantly in those cases. It was long intended to also amend the DFSG after 2004_003 to resolve these unfortunate ambiguities, but the outfall from that decision (and the subsequent retirement of the drafter) have basically shelved those changes. The GR as drafted is limited only to the interpretation of section 2 (ignoring point D, which is disparate) so any effect upon other sections is purely in the mind of the reader. P.S.: Please go on Cc:ing me, as I am not a subscriber. Thanks. It would make my life easier if you would preserve the Mail-Followup-To: then. Don Armstrong -- Miracles had become relative common-places since the advent of entheogens; it now took very unusual circumstances to attract public attention to sightings of supernatural entities. The latest miracle had raised the ante on the supernatural: the Virgin Mary had manifested herself to two children, a dog, and a Public Telepresence Point. -- Bruce Sterling, _Holy Fire_ p228 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: draft ballot for the firmware vote
On Fri, 06 Oct 2006, Sven Luther wrote: Manoj, if you don't stop this manipulation now, i am going to ask for your recall as secretary, not sure if this is possible under the constitution. Manoj has not done *ANYTHING* that requires secretarial powers so far. Indeed, the secretary *CANNOT* issue a call for votes unless they are the proposer or sponsor of a resolution which will appear on the ballot. The only thing Manoj can do, which he has not yet done to my knowledge, is alter the ballot from what the person calling for a vote has suggested. During weeks, you have resisted bringing the original proposal from frank to vote, Only the proposer or a sponsor can make a call for votes; if Frank wanted to bring the proposal to a vote, he could have done so himself. Since he hasn't, claiming that Manoj has resisted bringing the original proposal to a vote is incorrect. and now, because there are new proposals you dislike, you are going to rush the election. This is a clear abuse of your Secretarial position, and is not in order. There's nothing wrong with calling for a vote at any point after the minimum discussion period has elapsed. If you haven't submitted appropriate amendments by that point in time, then it's no one else's fault but your own. [If they haven't been seconded by enough people, then they just weren't popular enough.] These proposals have been around for weeks, they've been discussed for weeks. Lets get on with it. Don Armstrong -- I shall require that [a scientific system's] logical form shall be such that it can be singled out, by means of emperical tests, in a negative sense: it must be possible for an emperical scientific system to be refuted by experience. -- Sir Karl Popper _Logic of Scientific Discovery_ §6 http://www.donarmstrong.com http://rzlab.ucr.edu
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
On Fri, 06 Oct 2006, Frans Pop wrote: My, just as amateurish, standpoint is: the preferred from of modification of code for firmware blobs included in a driver that is otherwise coded in C (or assembler or whatnot) - and for that matter for images, video and even documentation - is whatever the licenceholder chose to distribute it as. This is not the case. A trivial counter example is the distribution of a binary object which is statically linked to (or otherwise in combination forms a derivative work of) a GPLed codebase, where the copyright holder of the binary object does not (completely) control the copyright of the GPLed codebase. Unless the binary object is actually the prefered form for modification, anyone who distributes the work does so in violation of the GPL (or possible future violation if distributed under 3b). Any copyright holder of the GPLed codebase (or for that matter, any recepient of the work) can demand the source code to the binary object. If we as distributors are unable to provide it, we (or our mirror operators) could be held liable. If you have specific questions about what the GPL says and means, please contact [EMAIL PROTECTED] to clarify it before putting the archive in a position which is legally hazardous. Don Armstrong -- Every gun that is made, every warship launched, every rocket fired signifies in the final sense, a theft from those who hunger and are not fed, those who are cold and are not clothed. This world in arms is not spending money alone. It is spending the sweat of its laborers, the genius of its scientists, the hopes of its children. This is not a way of life at all in any true sense. Under the clouds of war, it is humanity hanging on a cross of iron. -- Dwight Eisenhower, April 16, 1953 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for voting period to start on the firmware vote
On Thu, 05 Oct 2006, Manoj Srivastava wrote: On Thu, 5 Oct 2006 17:04:32 +1000, Anthony Towns aj@azure.humbug.org.au said: I don't think it's worth further delaying this vote to include this position statement; as per [0] the minimum discussion period for Manoj's amendment as accepted by Frederik [1] ended 4th Oct 2006 19:53:58 UTC, which is about 11 hours ago; so we could get on with calling for a vote and have this over and done with in a little over a week if the proposers and seconders are willing. [0] http://lists.debian.org/debian-project/2006/10/msg5.html[1] http://lists.debian.org/debian-vote/2006/09/msg00567.html This is a call for votes to start on the firmware resolution: The proposed ballot is: [ ] Release Etch even with kernel firmware issues [ ] Special exception to DFSG #2 for firmware as long as required [3:1] [ ] Further discussion I'm attaching the proposed WML page for this vote (vote_007.wml). Are there any objections to shortening the vote period for this vote? Don Armstrong -- LEADERSHIP -- A form of self-preservation exhibited by people with autodestructive imaginations in order to ensure that when it comes to the crunch it'll be someone else's bones which go crack and not their own. -- The HipCrime Vocab by Chad C. Mulligan (John Brunner _Stand On Zanzibar_ p256-7) http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Summary? (Or: my vote is for sale!)
On Tue, 03 Oct 2006, Marc Haber wrote: For the editorial changes GR, I didn't have the time to follow the entire flamewar and voted in belief that the changes were indeed editorial because I believed in the text in the CfV. As much as I hate to be caustic,[1] if DDs don't have time to exercise their franchise completely, by examining the proposals in detail and thinking about the repercussions they have, then they should vote the null ballot, ranking all options equally. Voting based on incomplete understanding over many years is what has lead my country to be in its current position.[2] Don Armstrong 1: Although some of you in the peanut gallery may claim that I enjoy it... 2: If you want to commiserate or comment on this, please do so privately. -- Debian's not really about the users or the software at all. It's a large flame-generating engine that the cabal uses to heat their coffee -- Andrew Suffield (#debian-devel Fri, 14 Feb 2003 14:34 -0500) http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The current GR
On Sun, 01 Oct 2006, Sven Luther wrote: i doubt that this was intented, and i am very curious about how such a work can indeed be distributing sources. The work is anthropomorphized there; unless the work is an AI (or has Affero-like code) it obviously can't do the distribution itself; agents do it on behalf of the work. [Much like a book cannot tell you anything but by the action of an agent reading the words on the page. However, we still can refer to books talking to us.] Don Armstrong -- There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Bach http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
