Re: abiftool, awt, and devotee development
On Thu, 15 Aug 2024, Rob Lanphier wrote: > My main reason for writing this mailing list is to ask for help on a couple > 2. There's a text format (called "Aggregated Ballot Information Format" or > "ABIF") that I've helped create, and I'm hoping folks familiar with the > devotee codebase would be willing to look at the format, and maybe even add > ABIF support to devotee. There's a pretty similar format[0] that I made pocket-devotee[1] consume that we use for most CTTE votes (which are public, but have a limited number of voters). devotee itself uses its tally format which pocket-devotee also can consume. As far as developers of devotee, I think it's basically Kurt Roeckx and Manoj Srivastava. Not sure how active they are in voting theory. [I personally don't have spare cycles, so I'm not of much use to you. Sorry!] 0: https://salsa.debian.org/debian/tech-ctte/-/blob/master/resolved_issues/893200_TC_Chair_election/run_vote.sh 1: https://salsa.debian.org/debian/tech-ctte/-/blame/master/scripts/pocket-devotee?ref_type=heads#L198 -- Don Armstrong https://www.donarmstrong.com I stared at the mountain rising over me. Empty. It was a pointless thing to have done -- climb up it, across it, and down it. Stupid! It looked perfect; so clean and untouched, and we had changed nothing. [...] I had been on it too long, and it had taken everything. -- Joe Simpson "Touching the Void" p117
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 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 > 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, 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: [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: "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: 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: 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: 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: > + > +A Developer is not eligible to be appointed to the Technical Committee > +if they have been a member within the previous 12 months. > + > + [...] > + > + > +Membership 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. > + > +When 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. > + > 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 , 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: Three common voting errors - how to avoid them
On Tue, 05 Oct 2010, Russ Allbery wrote: > I get bitten by this every time and it drives me nuts. I realize > that the point of sending out the ballot before the opening of > voting is so that, if there are last minute errors, they can be > corrected before any votes are counted, but my reaction upon seeing > the ballot is always to vote right away. Probably it'd be enough to send the preliminary ballot to -vote, with an appropriate reply-to set[1], but just reject any messages to the address. When the voting period starts, send the final ballot to -announce using at or similar. Don Armstrong 1: maybe also ░█▀▄░█▀▄░█▀█░█▀▀░▀█▀ ░█░█░█▀▄░█▀█░█▀▀░░█░ ░▀▀░░▀░▀░▀░▀░▀▀░ or similar. (toilet -f pagga draft) -- 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 debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101006003713.ge3...@rzlab.ucr.edu
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, 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: 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, 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: 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.
4.2. Procedure
The 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.
Delaying a decision by the Project Leader or their Delegate:
If 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).
[-If such-]
{+When+} 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).
If 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.-]
{+hold immediately.+}
[...]
Q 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.
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 @@
-The 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.
+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.
@@ -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).
- If 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).
-
- If 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.
+ 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.
If 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 @@
-Q 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.
+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.
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
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
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: 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: > 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 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 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, Guido Trotter wrote: > Well, let's say you should not propose or second an option you don't > plan to rank above "further discussion". I agree. "Rank first" is a bit absolutist; "Rank highly" is more appropriate, and what I used in later mails in this thread. 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
[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: 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: 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 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 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 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 Sat, 16 Feb 2008, Bas Wijnen wrote: > Yes, that too. :-) But as I wrote, for the 50% situation, there is a > reason we want that. We want to say "there are more people in favour > than against". With the supermajority, we want to say "there are > many more people in favour than against". Right. My main point is that for pathologically small values of voters such as this, changing the meaning of super-majority to include equality means that there is no effective difference between majority and super-majority. Perhaps this is a bug that should be solved by increasing the TC membership instead. [If 7 people are voting, suddenly all of these issues go away; 4/3, 5/2, and 6/1 become the magic numbers for N of 1, 2 and 3.] > When the actual value is arbitrary anyway, it makes sense to solve > it. All of the values we pick are going to be arbitrary to at least some degree, so this isn't terribly convincing to me. Don Armstrong -- It has always been Debian's philosophy in the past to stick to what makes sense, regardless of what crack the rest of the universe is smoking. -- Andrew Suffield in [EMAIL PROTECTED] 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=167556&cid=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 Wed, 01 Aug 2007, Wouter Verhelst wrote: > On Wed, Aug 01, 2007 at 02:30:31PM +1000, Anthony Towns wrote: > > Personally, I think annual elections are a good thing, pretty much for the > > reasons outlined by Jeff in: > > > > http://lists.linux.org.au/archives/linux-aus/2005-July/msg00030.html > > I'll summarize those as "if people want continuity in people on (the > board/the DPL position/whatever), they can re-elect them". > > I don't think it works that way. Given an apparently non-active > incumbent and a much-promising challenger, people are more likely to > vote for the much-promising challenger (provided this challenger is > promising what the electorate wants, of course). Part of this really comes down to communication, though. It's often only at election time that we start to get an inkling of the constraints which have been placed on the end-of-term DPL and what needs to be done to actually realize the goals initially promised. Not communicating successfully what is happening as the DPL (and often more importantly, what is blocking and/or stoping things from happening) is one of the reasons why incumbant DPLs have a hard time getting re-elected. I've no real problem with failing to re-elect in these cases. Don Armstrong -- The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair. -- Douglas Adams _Mostly Harmless_ 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 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, 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: 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: 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-, T&S- > > and P&P check > > I think this is the wrong time. My opinion of current T&S 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 T&S section's format is entirely up to the AM; lots of AMs use the current T&S 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 T&S 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; T&S 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 T&S, or P&P 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: Debian Maintainers GR Proposal
On Thu, 21 Jun 2007, Bastian Venthur wrote: > Sorry, but why don't we improve our New Maintainer (NM) process > instead of adding yet another layer of bureaucracy? This is an attempt to improve the NM process, actually. [The goal of the NM process is to get people in a position so that they are capable of contributing to Debian.] > Why don't we just grant NMs the same rights as you proposed for the > new Debian Maintainer (DM) class after they have been advocated (or > after T&S)? This process would allow that to happen. If the AM felt that an applicant was ready at the T&S stage, they'd advocate them at that point. It merely adds an additional method, whereby other people could advocate the developer outside of the NM process. It's not clear at all to me that an additional method is adding another layer of bureaucracy; it's very much the opposite, since it reduces the amount of tracking and verification of applicants that has to be done. > So, why such a complicated GR introducing second class DDs? The very fact that there is dissension is why the GR has been proposed; it could of course be done by fiat by ftpmaster, but getting DDs to agree to the process and comment on it is a healthy way forward. Don Armstrong -- For a moment, nothing happened. Then, after a second or so, nothing continued to happen. -- 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]
Re: Debian Maintainers GR Proposal
On Thu, 21 Jun 2007, Anthony Towns wrote: > 1) A new keyring will be created, called the "Debian maintainers keyring". >It will be initially maintained in alioth subversion using the jetring >tool, with commit priveleges initially assigned to: > > * the Debian Account Managers (Joerg Jaspert, James Troup) > * the New-maintainer Front Desk (Christoph Berg, Marc Brockschmidt, > Brian Nelson) > * the FTP masters (James Troup, Ryan Murray, Anthony Towns) > * the Debian Keyring maintenaners (James Troup, Michael Beattie) > * the Jetring developers (Joey Hess, Anthony Towns, Christoph Berg) My only concern here is that it seems like we have a lot of people who are responsible for the keyring; do we need to work on a slightly more fleshed out framework for acceptance so that all of them are coordinated? > 2) The initial policy for an individual to be included in the keyring >will be: > > * that the applicant acknowledges Debian's social contract, > free software guidelines, and machine usage policies. How do we plan on checking this? > * that at least one Debian developer (preferable more) is willing > to advocate for the applicant's inclusion, in particular to the > fact that the applicant is technically competent and good to work > with. Do the people who are going to be involved in maintaining the keyring have a proposal for how to verify this? Don Armstrong -- Those who begin coercive elimination of dissent soon find themselves exterminating dissenters. Compulsory unification of opinion achieves only the unanimity of the graveyard. -- Justice Roberts in 319 U.S. 624 (1943) 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=167556&cid=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: 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]
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 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
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: 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: 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: 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]
