Re: Candidates question: politics and Debian
On Tue, Mar 19, 2024 at 09:38:26AM +0100, Gerardo Ballabio wrote: I would point out to the candidates that Gerardo is not a voting member of the Debian project. I don't think we should allow our candidate discussions to be hijacked by non-voters. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: General resolution: Condemn Russian invasion of the Ukraine
On Thu, Mar 31, 2022 at 02:39:31PM +0200, Jonas Smedegaard wrote: > Quoting Julian Andres Klode (2022-03-31 12:31:18) > > Under 4.1.5 of the Constitution, the developers by way of GR are the > > body who has the power to issue nontechnical statements. > > This is a proposal for Debian to issue a statement on an > > issue of the day as given as an example, the recent invasion > > of Ukraine. > > Text of GR > > The Debian project issues the following statement: > > The Debian project strongly condemns the invasion of Ukraine by > > Russia. The Debian projects affirms that Ukrain is a souvereign > > nation which includes the Donbas regions of Luhansk, as well as > > Crimea, which has already been illegaly annexed by Russia. > No we don't - we care about our users, and our users include those who > do evil. I think this thread has largely petered out, with many people having laid out the reasons why Debian taking a public position on this is not necessarily a good idea. But I don't think it should go unadddressed that it's quite a bizarre twist to go from "our priorities are our users and Free Software" to "we care about evil users". "Our priorities are our users and Free Software" means that, in our decision making and our governance we should be oriented FIRST towards users and do what is good for the people who are using our software; and that our SECOND priority, only when not in conflict in the first, is to promote Free Software. That is far different from "people who are doing evil are using Debian, and therefore we should support them". Now, there are quite a lot of people who do evil and use Debian, most of which happens well outside the context of a geopolitical conflict. It is unrealistic to stop evil people from using Debian (or to stop Debian users from doing evil). But that doesn't mean people doing evil should somehow get a free pass from us because they are Debian users. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: opinion on Choice 1
On Mon, Apr 05, 2021 at 03:03:48PM +0200, Pierre-Elliott Bécue wrote: > Le dimanche 04 avril 2021 à 16:37:15-0700, Steve Langasek a écrit : > > On Sun, Apr 04, 2021 at 03:09:10PM +0200, Bernd Zeimetz wrote: > > > On Tue, 2021-03-30 at 12:18 +0200, Ulrike Uhlig wrote: > > > > People without voting rights repeatedly tried to lobby or push for a > > > > certain agenda on this list. > > > Welcome to Debian. > > > People are free to express their opinion, even if they are not owning > > > an @debian.org email address. And that is actually a very good thing. > > > The interested reader is able to filter messages and maybe maintain a > > > list of people to ignore if needed. It might be annoying for you, but > > > free speech is not always fun. > > People are free to express their opinion. That does not mean the Debian > > Project is obligated to provide a platform for those opinions on the > > debian-vote mailing list, which exists to facilitate discussions among > > voting members of the Debian Project regarding matters that will be voted > > on. > > Non-voting posters to debian-vote are almost exclusively outside agitators > > and there's no reason subscribing to debian-vote should mean receiving their > > bullshit in our mailboxes. > Even though it's hard and can be tiresome to many of us (and maybe > drives some away), as long as possible, I'd like the majority of our > lists to stay open to all people willing to express something. > Blocking potentially relevant comments from non contributors because > some trolls are trying to wreck havoc is giving them too much importance > and therefore giving them an easy victory. Can you point to an example of a post you consider actually (not "possibly") relevant from a non Debian voter to debian-vote in the past 2 years? Why should we allow third parties to lobby Debian electors using our mailing list infrastructure? > And, despite what I personally think, a non-contributor calling the RMS > vote a "witch hunt" is not necessarily a troll. I never used the word "troll", which for me has a very specific meaning grounded in its historical usage in online communities. I referred to them as "outside agitators", which I believe they are - whether or not a particular individual's intention is to derail the discussion, it is certainly their intention to influence the outcome of Debian's decision process according to their own interests, whether or not those align with the interests of the Debian voters as a democratic body. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: opinion on Choice 1
On Sun, Apr 04, 2021 at 03:09:10PM +0200, Bernd Zeimetz wrote: > On Tue, 2021-03-30 at 12:18 +0200, Ulrike Uhlig wrote: > > People without voting rights repeatedly tried to lobby or push for a > > certain agenda on this list. > Welcome to Debian. > People are free to express their opinion, even if they are not owning > an @debian.org email address. And that is actually a very good thing. > The interested reader is able to filter messages and maybe maintain a > list of people to ignore if needed. It might be annoying for you, but > free speech is not always fun. People are free to express their opinion. That does not mean the Debian Project is obligated to provide a platform for those opinions on the debian-vote mailing list, which exists to facilitate discussions among voting members of the Debian Project regarding matters that will be voted on. Non-voting posters to debian-vote are almost exclusively outside agitators and there's no reason subscribing to debian-vote should mean receiving their bullshit in our mailboxes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Willingness to share a position statement?
On Wed, Mar 31, 2021 at 09:12:24AM +1100, Dmitry Smirnov wrote: > On Wednesday, 24 March 2021 11:38:25 PM AEDT Steve McIntyre wrote: > > Freedom of speech does *not* mean freedom from consequences. > Here is a good reply to this very statement: > ~~~ > "Freedom of speech is supposed to imply freedom from quite a wide range > of possible consequences; mostly consequences like fines or incarceration, > but the spirit of it applies more broadly than that. If I were to say that > [whoever] is free to speak, but I wouldn’t guarantee there would be no > consequences for that speech, wouldn’t it be fair to interpret my words > as a veiled threat? > > The only valid “consequences” for an act of free speech is a solid rebuttal. > > If you think otherwise, then I suggest that you haven’t quite grasped the > point of the concept, or that you simply have tyrannical tendencies > (as many do). > ~~~ That's why facebook and twitter are full of well-informed people engaged in reasoned discussions, right? Oh no wait, it's the exact opposite, because it's far cheaper to disseminate stupid and toxic ideas than it is to convince people of complicated and accurate ones. Turns out the marketplace of ideas is actually the Home Shopping Network. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms
On Sat, Mar 27, 2021 at 12:20:22PM +0100, Mathias Behrle wrote: > > > Language quip: Not "invited to do this in person" (personally flying > > > to wherever signatures are being gathered), but "in a personal > > > capacity" or "as an individual action"... ? > > I think the intention was clear, but I'm fine with a version which > > changes that part as suggested above and my seconds extends to such a > > version. > Exactly my thoughts. I would be glad to hear from a native speaker if the > wording is really capable of being misunderstood. Otherwise I just would let > go. But I second also the proposed version, preferable using then "as an > individual action". "in person" has a pretty unambiguous meaning in (American?) English referring to physical presence, so is the wrong thing to say here for your intent. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: The "RMS Open Letter" is based on lies, misrepresentations, and misinformation
I certainly don't. The problems at issue are amply documented on the Internet and I'm not going to debate them here. You don't have to vote for the GR, and I'm not going to waste time knocking down strawmen from a third party in order to persuade you. On Fri, Mar 26, 2021 at 02:08:24PM +, Ximin Luo wrote: > Does anyone have a response to this? > > The current efforts really smells of a witch-hunt and an attempt to > manufacture consent. > > Ximin > > James Lu: > > This is my first time posting in a Debian mailing list, apologies if the > > tone or is not what you are looking for in a Debian post. I wrote this > > hurriedly in an attempt to help the free software movement avoid > > splintering. > > Stallman asked women out in a way we consider creepy. The letter phrases > > this by saying Stallman has sexually harassed women for decades. The letter > > seeks to group him in the same category as gropers and actual rapists. > > In 1993, he defined pedophilia slightly differently. He made a genuine > > apology. This is the basis of the "pedo apologist." > > https://stallman.org/archives/2019-jul-oct.html#14_September_2019_(Sex_between_an_adult_and_a_child_is_wrong) > > > > <https://stallman.org/archives/2019-jul-oct.html#14_September_2019_(Sex_between_an_adult_and_a_child_is_wrong)> > > After condemning the rape of a 17 year old girl in the Epstein case, Marvin > > Minksy had sex with the girl, unaware the girl was being coerced by > > Epstein. In accordance with the law of Canada and most U.S. states, it is > > legal to have sex with a 16 year old girl. Nonetheless, we believe these > > leaked private discussions make him equivalent to a rapist. > > https://geoff.greer.fm/2019/09/30/in-defense-of-richard-stallman/ > > <https://geoff.greer.fm/2019/09/30/in-defense-of-richard-stallman/> > > The original open letter's Appendix has two true claims of sexual > > harassment: > > - In 1999, he had a mattress in his office which he slept on. This made > > some women avoid RMS because they considered it abnormal and creepy. > > - In 1985, he told a woman he'd kill himself if he didn't date her. > > The "hot ladies" nametag was fake; it was vandalized from a third party. > > https://blog.dachary.org/2020/02/10/how-the-cancel-culture-was-leveraged-against-rms/#post-4297:~:text=As%20for%20the%20label%20on%20Richard,removed%20the%20ending%3A%20(also%3A%20hot%20ladies) > > > > <https://blog.dachary.org/2020/02/10/how-the-cancel-culture-was-leveraged-against-rms/#post-4297:~:text=As%20for%20the%20label%20on%20Richard,removed%20the%20ending%3A%20(also%3A%20hot%20ladies)> > > He has never been accused of groping or sexual assault. > > Stallman has hundreds of posts on his personal blog condemning rape, and > > they cherry-pick the one post where he argued for a different definition of > > rape. > > https://web.archive.org/web/20210325013942/https://stallman.org/archives/2018-may-aug.html > > > > <https://web.archive.org/web/20210325013942/https://stallman.org/archives/2018-may-aug.html> > > The GNU Kind Communication Guidelines ask you to honor gender identity. The > > letter says it is "still transphobic" and accuses him of "thinly disguised > > transphobia," possibly because it includes calling someone via only > > gender-neutral pronouns such as "they." > > I strongly urge everyone to avoid splintering the free software movement. I > > understand you do not want to be associated with racism, sexism, > > transphobia, and ableism. The accusers do indeed label anyone who don't > > agree with them as sexist and transphobic. This is how they did it in > > McCarthy era.[0] Resist the urge to be performative and stick to principles. > > > > [0]: https://www.aclu.org/other/what-censorship > > <https://www.aclu.org/other/what-censorship> > > > -- > GPG: ed25519/56034877E1F87C35 > https://github.com/infinity0/pubkeys.git > -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Willingness to share a position statement?
On Fri, Mar 26, 2021 at 10:05:44AM +0100, Gerardo Ballabio wrote: > Steve McIntyre wrote: > > We *entirely* have the freedom to discriminate based on > > what people say and do around us. We're not a government. > > So only governments should not discriminate people? > > > Try a simple thought experiment: if you think that only the law (which > > country?) has any bearing here, is spam filtering allowed? Should we > > be allowed to block people from our mailing lists or BTS for sending > > lots of messages saying "Free Software is awful"? > You have the right to choose which mail messages you receive. > You haven't the right to choose which mail messages I send. > Can you see the difference? Debian as a project has a right to block your mails so they are not dissemminated via our servers. > Similarly, if you don't want to listen to me, you have the right to > walk away. You haven't the right to silence me. > If you don't want to work with me, you have the right to quit. You > haven't the right to get me fired. Obviously false. You do not have a right to be the most obnoxious person in your place of work who drives other people to quit, and people have a right to demand a work environment free from harrassment. And why are we having this conversation? You're not a Debian developer, you told Debian you were leaving because you disagreed with our policies, and you don't get a vote. Do you think you're persuading someone here? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: ***UNCHECKED*** Re: Re: Willingness to share a position statement?
On Fri, Mar 26, 2021 at 06:47:31AM -0400, Miles Fidelman wrote:
> Christian Kastner wrote:
> > On 26.03.21 01:06, Simon Richter wrote:
> > > >(2) how deeply Debian gets involved
> > > We are in a prominent position. The OSI's Open Source Definition is
> > > derived from the Debian Free Software Guidelines, after all, not the
> > > other way 'round.
> > >
> > > There is no way for us to not be involved in something that affects the
> > > whole free software community.
> > Sure, but we have a choice as to how we get involved -- the specific
> > actions, or inaction. See the ongoing GR.
> >
> > All I'm saying is that when people speak out about the wish to be
> > apolitical, the term 'apolitical' should not be taken in the widest
> > possible sense, which covers any action or inaction, and then dismissed
> > for being impossible.
> > Rather, in should be understood in a stricter sense, namely of favoring
> > inaction ("political inactivism", if you like).
> If one wants to talk political - maybe it's time to survey the Debian
> community as to who feels how about Stallman. Otherwise this is all a based
> on a few loud voices shouting at each other.
LOL what do you think a vote is
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
Re: Willingness to share a position statement?
On Thu, Mar 25, 2021 at 06:28:36PM -0400, Roberto C. Sánchez wrote: > On Thu, Mar 25, 2021 at 10:20:33PM +, Steve McIntyre wrote: > > On Fri, Mar 26, 2021 at 12:09:40AM +0200, Adrian Bunk wrote: > > >On Thu, Mar 25, 2021 at 09:38:56PM +, Steve McIntyre wrote: > > >>... > > >> We *entirely* have the freedom to discriminate based on > > >> what people say and do around us. We're not a government. We are *not* > > >> in the situation where we *have* to support people saying things that we > > >> believe to be bad, wrong and hurtful. It is *entirely* within our > > >> rights to evaluate people by their words and actions and to decide > > >> whether we wish to talk or work with them in future. > > >>... > > >You are saying companies should always have the right to fire employees > > >if they join an union. > > Not at all, please don't twist my words. > > Unfortunately, there *are* many places around the world where > > companies can do exactly that. There are many others where rights like > > this are enshrined in other laws. Debian is not an employer here, so I > > don't think your point is relevant? > I would hardly call it twisting your words. > Either private individuals and entities have freedom of association, or > they do not. You can't have it both ways. Freedom of association means the freedom to associate with who you chose to and the freedom to *not associate with people you don't*. It is an infringement of the freedom of association of all other Debian developers if we are not able to exclude someone based on the views they express and the actions they take. Labor rights are entirely different from "freedom of association". -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Willingness to share a position statement?
On Thu, Mar 25, 2021 at 01:59:25PM -0400, Roberto C. Sánchez wrote: > Why not dispense with the vote and simply have the DPL sign for the > project? Then at least those who are not in agreement will not feel > directly targeted, though they may disagree with the outcome. Constitutionally, this is not permitted. The DPL does not have the authority to issue non-technical statements on behalf of the project. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Asking DPL to shorten Discussion Period for rms-open-letter
On Thu, Mar 25, 2021 at 12:13:19AM +0200, Jonathan Carter wrote: > On 2021/03/24 23:19, Sam Hartman wrote: > > I suspect that the issues surrounding the open letter asking rms to step > > down and for the FSF board to resign are fairly well understood at this > > point. > > It's been an ongoing issue. > > > > I don't think we're going to get much benefit out of a prolonged > > discussion, and I think that there is significant benefit in acting > > quickly in this instance. > > So, I'd like to ask the DPL to consider shortening the discussion > > period. > > > > It's possible that circumstances may arise requiring more > > than a week's discussion. > > But unless that happens I think we would all be happier spending less > > rather than more time on this issue. > > I suspect most people already have their minds made up. > > If Steve, as proposer of the GR is comfortable with shortening the > discussion period to one week, then I will use the DPL powers as per > section 4.2.4 of our constitution to enact that. I am more than happy with this. I see no reason for a prolonged discussion. Ratifying someone else's statement is by its nature an up or down vote. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io
On Wed, Mar 24, 2021 at 10:16:44PM +0100, Nicolas Dandrimont wrote: > On Wed, Mar 24, 2021 at 01:54:16PM -0700, Steve Langasek wrote : > > Under 4.1.5 of the Constitution, the developers by way of GR are the body > > who has the power to issue nontechnical statements. > > > > https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md > > is a statement which I believe Debian as a project, and not just individual > > Debian developers, should consider signing on to. > > > > This is a proposal for Debian to sign on to the statement, by adopting the > > text from that open letter via GR. > > > > Text of GR > > > > The Debian Project co-signs the statement regarding Richard Stallman's > > readmission to the FSF seen at > > https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md. > > > > The text of this statement is given below. > > > > [...] > > > > End Text of GR > Seconded. > (I'll also second an amended text with s/FSF/FSF board/ or equivalent > correction) I accept an amendment to include the word "board" (which was missed on accident by me) and would ask the seconders to confirm their acceptance of this amendment so we can avoid any unnecessary extra variations on the GR ballot. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io
Under 4.1.5 of the Constitution, the developers by way of GR are the body who has the power to issue nontechnical statements. https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md is a statement which I believe Debian as a project, and not just individual Debian developers, should consider signing on to. This is a proposal for Debian to sign on to the statement, by adopting the text from that open letter via GR. Text of GR The Debian Project co-signs the statement regarding Richard Stallman's readmission to the FSF seen at https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md. The text of this statement is given below. Richard M. Stallman, frequently known as RMS, has been a dangerous force in the free software community for a long time. He has shown himself to be misogynist, ableist, and transphobic, among other serious accusations of impropriety. These sorts of beliefs have no place in the free software, digital rights, and tech communities. With his recent reinstatement to the Board of Directors of the Free Software Foundation, we call for the entire Board of the FSF to step down and for RMS to be removed from all leadership positions. We, the undersigned, believe in the necessity of digital autonomy and the powerful role user freedom plays in protecting our fundamental human rights. In order to realize the promise of everything software freedom makes possible, there must be radical change within the community. We believe in a present and a future where all technology empowers – not oppresses – people. We know that this is only possible in a world where technology is built to pay respect to our rights at its most foundational levels. While these ideas have been popularized in some form by Richard M. Stallman, he does not speak for us. We do not condone his actions and opinions. We do not acknowledge his leadership or the leadership of the Free Software Foundation as it stands today. There has been enough tolerance of RMS’s repugnant ideas and behavior. We cannot continue to let one person ruin the meaning of our work. Our communities have no space for people like Richard M. Stallman, and we will not continue suffering his behavior, giving him a leadership role, or otherwise holding him and his hurtful and dangerous ideology as acceptable. We are calling for the removal of the entire Board of the Free Software Foundation. These are people who have enabled and empowered RMS for years. They demonstrate this again by permitting him to rejoin the FSF Board. It is time for RMS to step back from the free software, tech ethics, digital rights, and tech communities, for he cannot provide the leadership we need. We are also calling for Richard M. Stallman to be removed from all leadership positions, including the GNU Project. We urge those in a position to do so to stop supporting the Free Software Foundation. Refuse to contribute to projects related to the FSF and RMS. Do not speak at or attend FSF events, or events that welcome RMS and his brand of intolerance. We ask for contributors to free software projects to take a stand against bigotry and hate within their projects. While doing these things, tell these communities and the FSF why. We have detailed several public incidents of RMS's behavior. Some of us have our own stories about RMS and our interactions with him, things that are not captured in email threads or on video. We hope you will read what has been shared and consider the harm that he has done to our community and others. End Text of GR -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Willingness to share a position statement?
On Wed, Mar 24, 2021 at 12:19:44AM +0100, Adam Borowski wrote: > On Tue, Mar 23, 2021 at 04:56:39PM -0600, Gunnar Wolf wrote: > > Hello, > > I hope not to be too inflamatory with this. As you are surely aware, > > last week Richard Stallman was reinstated as part of the Board of > > Directors of the FSF. That is something deeply disturbing and > > confidence-shattering for many of us. > > Some people have moved to action -- if nothing more, at least to > > express they are disgusted with the turn of events > I'm also disgusted with such hatred towards the person who started the > whole "Free Software" thing, and personally did most of the work in the > early days. Holding people accountable is not hatred, you floating point error. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: [draft] Cancel this year's in-person Debian Developers Conference DebConf20
Hi Stefano, I appreciate you taking the time to lay out the thought process. Even though this is indeed now academic, since there is no decision we will actually be disputing with a GR, I want to reply to one particular subpoint to make it clear exactly where I'm coming from. On Wed, Jun 03, 2020 at 06:39:53PM +, Stefano Rivera wrote: > Would it be totally unrealistic, and unsafe to bring a large number of > people together? Probably, yes. But if the local authorities are saying > you can, it's worth considering. This is the part that I categorically disagree with. Even assuming baseline competence of the local authorities (which, given that they're not in the US, I'm willing to give them the benefit of the doubt), this only speaks to the authorities' confidence in their ability to prevent a SARS-CoV-2-positive attendee from causing a LOCAL outbreak that is a threat to public health. It says NOTHING about the risk of someone contracting COVID in their home country, arriving asymptomatic at the conference, being contagious and transmitting it, and sending the virus home to a dozen other countries to incubate for a week after the conference before the nature of the problem has become clear. If that happened, it would be entirely on the organizers (i.e. Debian), and not on the local authorities, because we were inducing people to travel internationally for the event. And if the conference were to manage this risk by imposing broad restrictions on countries of origin of physical attendees, then it shouldn't carry the DebConf name; it should be treated as a miniconf instead, due to the impact it would have on accessibility to the developer community to have an even smaller than usual subset of developers attending in person with most attending remotely. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: [draft] Cancel this year's in-person Debian Developers Conference DebConf20
On Tue, Jun 02, 2020 at 12:44:23AM -0400, Scott Kitterman wrote: > On Tuesday, June 2, 2020 12:12:21 AM EDT Bdale Garbee wrote: > > Scott Kitterman writes: > > > It's almost like this discussion about a GR was a premature waste of > > > everyone's time. > > It's also possible that discussion about a possible GR influenced the > > ultimate decision in a useful way. > > [shrug] > Sure, but doing business by threat of GR is a horrible way to run things. > What I would have hoped is that project members would trust the people that > they have (indirectly) delegated the responsibility to run Debconf to to do a > good job and only once there is something that's enough of a problem to > require a project wide decision to change their decision consider a GR. > There's enough to do to make the Debian project go that I don't think we need > to engage in project level micromanagement like this. The fact that the organizing team's response to the pandemic was anything other than a categorical decision not to hold a conference that would put people on planes and increase the overall risk of the community of disease transmission - and was instead in the nature of a public poll to find out whether there was enough *interest* in holding an in-person conference - means they had already lost any confidence I might have had in them in this matter. In this context, the rationale for the decision is as important as the decision itself. I did not trust them to do the right thing because they had already done the wrong thing. A GR under those circumstances looks entirely appropriate to me. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Some thoughts about Diversity and the CoC
On Fri, Dec 13, 2019 at 08:46:35PM +0100, Alexander Wirt wrote: > On Wed, 11 Dec 2019, Sam Hartman wrote: > > TL;DR: Treating people with respect is hard and very contextual. > > Choosing to change how you talk about something to make people more > > comfortable doesn't always mean you were obligated to make that change. > > Sometimes you're just promoting connection. > *snip* > today I had to write a bunch of mails in my role as one of the listmasters. > To be honest, I had better things to than doing that.. I want to remember > *everyone* on list (and of course on all other lists to) to follow our Coc [1] > and the l.d.o additions [2]. Beside of those formal things, I ask you all to > come down. Please remember, in the end we are just doing some stupid thing > like a linux distribution here. There are so many more important things like > a technical discussion. I don't know if this is what you intended, but it reads to me like you are saying here that a technical discussion is more important than Martina's concerns about transphobia in our community and trans people having their identity denied. I disagree and would consider that an unacceptable position for a Debian listmaster to take. > Thanks for your attention and please forgive me any usage of bad wording > or typos. I'm certainly happy to do this if that's what it is. But given the severity of the implications of the possible misinterpretation, I would ask that you please clarify. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Proposed amendment to Proposal D
Ian, I'd like to propose an amendment to your proposal D, to strike the sentence: We are disappointed that this has had to involve another GR. I have not decided yet how I'm going to vote in this GR, but I think that the above sentence can only weaken support for your proposal by conflating the question of what our init system policy should be, with meta commentary on the procedure used to decide that policy. I personally find it more difficult to support this proposal because of this mixing of concerns. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Debian Project Leader Elections 2019: Call for nominations
On Sun, Mar 10, 2019 at 11:47:52AM +0100, Daniel wrote: > On 10/03/2019 11:37, Steve McIntyre wrote: > > On Sun, Mar 10, 2019 at 11:20:03AM +0100, Daniel wrote: > >> On 10/03/2019 04:44, Steve Langasek wrote: > >>> This is an obviously untrue signature. > >> Why do you want to taint the elections with more bullying, insulting and > >> disrespectful comments? > > He's telling the truth, nothing more. > > Daniel, I don't know what you think you're trying to achieve here, but > That was explained in the platform, please read it again until you do > understand > > nothing positive is happening. Please stop. > Instead of making condescending comments like that, feel free to put up > your own platform or respond to the points in mine. But don't treat > other developers like children with silly comments like "Please stop" You began your message commenting that people had contacted you encouraging you to run for DPL. These people are either ignorant of, or indifferent to, Debian's constitutional framework. Rather than correcting any possible misunderstandings on the part of these individuals regarding your eligibility to stand for office, you are obliging them by posting a platform to this public mailing list that implies that you are a candidate for DPL, and directly misrepresents yourself as being a Debian Developer, which is not a status that you hold. You are clearly acting in bad faith. If I were to guess at your motives, I would presume you are playing to an audience of people who are not members of the Debian Project, in order to bring pressure to bear on the project on your behalf. But whether that is your motivation or not, it is unconstructive to engage in the substance of a platform that has been posted in bad faith. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Debian Project Leader Elections 2019: Call for nominations
On Sun, Mar 10, 2019 at 12:56:00AM +0100, Daniel wrote: > On 03/03/2019 01:17, Debian Project Secretary - Kurt Roeckx wrote: > > Please make sure that nominations are sent to (or cc:'d to) > > debian-vote, and are cryptographically signed. > A lot of people contacted me encouraging me to run for DPL as a way to > help Debian out of the current cultural and political problems. > Please judge my platform and ability to delivery rather than anything else. There are no provisions in the Debian constitution for non-Developers to be nominated for the position of DPL. > -- > Debian Developer This is an obviously untrue signature. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: DPL Voting period
On Sun, Apr 09, 2017 at 08:25:06PM +0200, Kurt Roeckx wrote: > On Sun, Apr 09, 2017 at 11:35:06AM +0200, Stefano Zacchiroli wrote: > > On Sat, Apr 08, 2017 at 07:34:34PM +0200, Kurt Roeckx wrote: > > > We're currently in the voting period, the discussion/campaigning > > > period is over. Can I please ask everybody to stop talking about > > > things related to the DPL election on this list. > > I'm not sure I understand why. Since when it is _forbidden_ to discuss > > outside the campaign period? > It was always my understanding that this was the case, and as far > as I know people have always stopped discussing after the > campaigning was over. I think this is largely true, but it is not written into the constitution. People's attitudes towards continued discussion on debian-vote during the voting period are probably heavily influenced by their local laws about campaign blackouts before elections in meatspace. While discussion on debian-vote usually wraps up once voting starts, I don't believe there's anything to be enforced here by the Secretary. > I also want to compare this to other elections. As far as I know, > as long as voting booths are open there are no interviews with > politicians, they don't make things like exit polls available and > so on. They only get to persuade people before the booths open. Right, this is not a universal physical law of elections, it's only a local law in some localities :) And I think the closest analogue to a Debian vote is a meatspace election that allows early or by-mail voting. I think there's almost universally some overlap between campaign periods and voting periods in those cases (but ICBW). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Question for DPL candidates: Teetotaler outreach
Hi Chris, On Fri, Mar 31, 2017 at 07:31:44PM +0100, Chris Lamb wrote: > > How do you plan to create a more welcoming environment for people not > > drinking alcohol, and reach out to teetotalers? > Great points, Adrian. Whilst not as rife in the free software word, alcohol > is almost used as a currency within Silicon Valley tech circles to bribe or > entice employee, with beer fridges listed as a perk and social events > happening at bars. > Whilst I've learnt over the years to accept that terms such as "go for a > pint" aren't meant to be taken 100% literally and — at least in the UK — > not drinking alcohol at social functions is becoming less of of a big deal, > I can totally relate that terms like "beersigning", the generic "I'll buy > you a beer" thank-you response and the general assumption that you would > imbibe can be a little frustrating and possibly even triggering. > In Debian, it would seem difficult to rename cherished events such as the > "Cheese & Wine BoF", but we could always advertise and underline ahead of > time that non-alcoholic beverages are available and actually ensure a > sufficient and interesting variety actually are. After all, not drinking > alcohol hardly implies a diet consisting entirely of Coca-Cola. > However, moderating the atmosphere so that non-drinkers do not feel like > they are unwelcome, perhaps by curbing excess in some of the drinkers, might > be the key here. As DPL, what standard will you use to determine that some developers are drinking to excess? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution
On Fri, Jul 08, 2016 at 03:27:56PM +0200, Margarita Manterola wrote: > > The Debian Constitution is very well written, in a way that is almost > completely > ungendered. The only gendered word left is the Chairman of the Technical > Committee. There is no reason for this position to be gendered. Ungendered > alternatives for Chairman are Chair and Chairperson. While both work, Chair is > simpler and shorter. > > I'm therefore proposing the following General Resolution: > > === BEGIN GR TEXT === > > Title: Replace "Chairman" with "Chair" throughout the Debian Constitution > > All appearances of the word Chairman shall be replaced with the word Chair. > > === END GR TEXT === > > This change can be applied by a simple sed command (s/Chairman/Chair/g). I'm > attaching the diff between the current constitution document and the output of > said sed command to make it explicit that no other changes are intended. Seconded. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Alternative proposal (+call for seconds): Expire 2-R members every year
On Mon, Dec 01, 2014 at 02:37:30PM +0100, Lucas Nussbaum wrote: Rationale - First, I think that there is wide agreement that a more regular turn-over among TC members would be a good thing. And both Stefano's and this proposal aim at addressing this, by ensuring that at least 2 members of the TC are replaced every year. However, too much turn-over, with more than 2 replacements at one point of time, might have negative effects too. The TC might be temporarily weakened by having more young members; replacing more than two members at one point will cause less replacements later; it increases the difficulty of finding new members. The recent situation, with three TC members resigning, should not be treated as exceptional in the context of this resolution. If it were to happen again, I don't think that we should add one or two automatic expirations to the three resignations. This proposal differs from the original proposal by counting all resignations and removals as part of the desirable 2 per year replacement rate, so that the total number of replacements does not exceed two if only one or two younger members decide to resign. This version of the proposal could even result in an internal TC discussion: OK, the Project wants two members to be replaced. Are there members that feel like resigning now? Or should we just fallback to the default of expiring the two most senior members?. I think that such a discussion would be a healthy way for each TC member to evaluate its status. The orignal proposal could have the detrimental effect of pushing inactive/demotivated members to stay on the TC until their expiration, to avoid causing additional churn. The pathological corner case here appears to be that the longest-serving member of the TC could evade the term limit indefinitely. A scenario that assumes good faith on the part of all TC members is: - The longest-serving member of the TC spends a minimum amount of time engaging with TC issues. They vote on all resolutions, but don't spend much time cross-examining the petitioners, nor do they participate in resolution drafting. From their perspective, they are doing their duty on the TC, but other members of the TC have a faster response time to issues and therefore wind up doing the bulk of the work. - The other members of the TC all are very passionate about their work on the committee. (They've all been serving less than 3 years, so they have a lot of passion for it.) They engage with every issue, spend several hours each week on trying to make the TC serve the needs of the project as best they know how. And once or twice each year, there is a big issue that lands on the TC's desk, with social and technical issues intertwined and that require a lot of energy to pick apart. Once a year, one of these issues further devolves into a public flamewar where the ethics of the TC members themselves are called into question. And as a result, two members of the TC per year resign. - With the minimum turnover requirement met, the longest-serving member continues to serve as long as they are comfortable doing so. Did you consider this corner case in your analysis? If you think this corner case is less important than the risk of high turnover in the TC, could you elaborate why you think this? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: draft alternative proposal: fix problem at the root
Hi Bill, On Fri, Dec 05, 2014 at 12:31:08AM +0100, Bill Allombert wrote: I am in favor of this option appearing on the ballot. I have been following the TC for 15 years, and it is clear to me that the cost of having a TC outweights the benefit (and I had the same opinion 5 years ago). There are very few developers I would trust on to be on the TC that are not TC members already, and they are the developers we can the least waste their time by have them sitting in the TC. I'm curious how you reach the conclusion that not having a TC means that the current TC members will have less of their time wasted. If we don't have a TC as a dispute resolution body, the only binding decision-making body will be the developers at large (through GR). I don't think having a project-wide discussion on every question that would have gone to the TC would take less time than having a TC discussion about the same question - and because everybody votes in a GR, everybody's time is wasted, not just that of the select few suckers^W noble servants^W^W unaccountable overlords on the TC. Do you think that eliminating the option of using the TC (by disbanding the TC) means that fewer disputes will be raised via our formal dispute resolution process? If so, how do you believe these disputes will be resolved, and why will this be a net improvement to Debian over the current process? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: GR proposal, Call for Seconds - term limit for the tech-ctte
On Mon, Dec 01, 2014 at 12:20:25PM +0100, Stefano Zacchiroli wrote: [ Cross post -vote, -project ; M-F-T: to -vote. For more background information on the development of this proposal, see https://lists.debian.org/debian-vote/2014/11/msg00274.html ] I'm hereby formally submitting the GR proposal included below between dashed double lines, and calling for seconds. With respect to past discussions on the -vote mailing list, this is the proposal code-named 2-S; see [1,2] for (the last known versions of) alternative proposals. [1]: https://people.debian.org/~zack/gr-ctte-term-limit/ [2]: http://git.upsilon.cc/?p=text/gr-ctte-term-limit.git;a=tree === The Constitution is amended as follows: --- --- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100 +++ constitution.2-S.txt 2014-11-21 16:56:47.328071287 +0100 @@ -299,8 +299,20 @@ Project Leader may appoint new member(s) until the number of members reaches 6, at intervals of at least one week per appointment. -5. If the Technical Committee and the Project Leader agree they may +5. A Developer is not eligible to be (re)appointed to the Technical + Committee if they have been a member within the previous 12 months. +6. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee. +7. Term limit: + 1. On January 1st of each year the term of any Committee member +who has served more than 42 months (3.5 years) and who is one +of the two most senior members is set to expire on December +31st of that year. + 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 +longer. In the event that a member has been appointed more +than once, only the most recent appointment is relevant. 6.3. Procedure --- As a transitional measure, if this GR is passed after January 1st, 2015, then the provision of section §6.2.7.1 is taken to have occurred on January 1st, 2015. === I'd like to thank Anthony Towns for introducing the term limit idea several months ago [3] and for his help in polishing it through several rounds of feedback on the -vote mailing list. [3]: https://lists.debian.org/debian-project/2014/05/threads.html#00054 Seconded. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [DRAFT #2] Maximum term for tech ctte members
On Wed, Nov 19, 2014 at 01:59:33PM +0100, Lucas Nussbaum wrote: On 19/11/14 at 12:25 +0100, Stefano Zacchiroli wrote: On Wed, Nov 19, 2014 at 11:37:25AM +0100, Lucas Nussbaum wrote: I fear that, by reducing the average 'age' from 7.8 years to ~2 years, we are going too far. I would like to make it easier, for some members, to stay members of the TC for longer than 4 years. OTOH, I don't want this decision to be taken lightly. Again, this is true only under the assumption that former members won't come back. But even with that assumption, it seems you're arguing for the fact that a term limit of 4.5 years (and therefore an average of about half of that, modulo the transition period) is too short. It's hard to judge that in the abstract, but my gut feeling is that it is in fact quite long. Volunteers, especially when active in stress-full roles, do need shorter cycles. I don't think that the TC is a stress-full role. snort -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
is not a way to decide this matter if Debian's majority doesn't believe it's appropriate to bundle those features in the first place. (N.B.: this doesn't require malice on the part of systemd upstream to be true. It may simply be a difference of philosophy between systemd upstream and the Debian project about what level of bundling is appropriate. That doesn't mean Debian should passively accept scope creep just because it's not malicious.) But whether or not the majority feels this is something that needs to be regulated, we should not be afraid of Debian following the will of the majority. Instead we should be afraid of Debian *not* doing so. Because not voting on the substance of this question, and leaving it to external forces to decide what kind of OS Debian will be in the future, ensures that the same uncertainty, anger and fear that has been distracting us for most of this year will persist for a very long time to come. There are some bad actors on the Internet who will continue to excoriate Debian for any decision they disagree with, and we should certainly not be swayed by those people. But the dissent is not just from the sexist trolls who should crawl back into their cave and let the mountain fall on their knotted heads. There are also a lot of Debian users who are afraid of what the future holds for an OS that they love very much; and they deserve to have that cloud of fear removed from over their heads, to be given closure, even if that closure brings the certainty that they will part ways with Debian rather than being reconciled to it. Here, things change -- it's worst for everyone if nobody does the work, but if someone else is doing the work, it's better for you to let them do it. That's the opposite of the prisoner's dilemma, in that both non-systemd and systemd users are better off if they cooperate by working on non-systemd support (as opposed to defecting by not working on it), but that's only true given there's compulsion in the first place. If you compare with and without the compulsion, the only circumstance that's different is that S is worse off if S and U both choose L, ie not-working on systemd support. I'm not sure that the GR proposals actually setup that sort of payoff matrix, though that's the impression that I get. If it is, I think compelled is a fair description of what's being attempted. It is a form of compulsion that is legitimate under our constitution. There are some times when letting every DD do their own thing is not the right way to build a shared operating system. This may or may not be one of those times; and I'm sure that some DDs will object to any compulsion by the project, whether it's constitutional or not. But I think you've laid out very well how, if one believes this is the OS we want to create, that such compulsion would benefit the project. Being compelled to stay within certain boundaries, and working together toward a common goal instead of treating the archive as a battleground, is not necessarily a bad thing. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Tentative summary of the amendments
On Sat, Oct 25, 2014 at 11:52:32AM -0400, Miles Fidelman wrote: Olav Vitters wrote: 3. That we tried to blackmail someone if it looks like a duck, and quacks like a duck.. 4. That it is about sysvinit scripts Again, of course it is. If you cannot, it seems you just performed libel. Suggest to be very careful in the claims you make. Actually, I suggest you to cease and desist. if you think my statement is libelous, go ahead and sue - I'd LOVE to have the behavior of those behind systemd to be more visibile. This is absolutely inappropriate and off-topic for this list. Neither you nor Olav have voting rights in Debian. Even if this were somehow an acceptable way for you to go about persuading Debian's voters, which it's not, you're not doing that - you're just addressing yourself abusively to someone else who is not a voter. Please stop. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Re: Re-Proposal - preserve freedom of choice of init systems
On Sat, Oct 18, 2014 at 03:26:57AM +0100, Jonathan de Boyne Pollard wrote: Perhaps if you picked something other than runit you'd make your point more effectively. Try using the case of someone who makes a tool that depends from System V init running as process #1. It is hardly farfetched. I've seen at least two people publicly point out in the past several months that they had something set up in /etc/inittab that broke when they switched to an alternative bootstrap system. (A lot of people conflate init with rc. It's not System V init that other bootstrap systems sometimes provide shims and compatibility mechanisms for. It's System V rc, more specifically the /etc/rc?.d/* scripts that it runs.) There's also a Debian bug or two. So the question that you should be asking to make your point is probably this: The resolution says that In general, software may not require a specific init system to be pid 1.. Does this mean that softwares that make use of /etc/inittab, which is peculiar to (in Ian Jackson's own words) a specific init system (its contents, outwith sometimes the run level line, being not processed at all by any of upstart, systemd, runit-init, s6-svscan, the nosh system or service managers, minit, jinit, or finit), are unfit for inclusion in Debian according to Ian Jackson's resolution? Yes, they almost certainly would be unfit for inclusion. Which is actually the status quo today, as inittab is a non-conffile config file with no management interface to permit additional packages to hook into it - making it a policy violation for other packages to edit this file. So I believe the requirements here are symmetric, and there's certainly no reason to think that the requirements are onerous because it would forbid integrating with /etc/inittab. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, Oct 16, 2014 at 08:26:21PM +0200, Ansgar Burchardt wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: I think that if necessary we might have to delay the release. That would be a matter for the release team. I would be very unhappy if we ditched the ability of people to choose a different init system simply to maintain our release schedule. Hurray, what a great idea to delay everything *now*. And all because some people believe in conspiracy theories about Red Hat... This response is uncalled for. The /existence/ of conspiracy nuts is no reason to insult the members of the Debian community who are unhappy with the increasingly monolithic approach to system design that is being advocated in some quarters. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: All DPL candidates: Debian assets
On Sun, Mar 30, 2014 at 07:55:54PM +0100, Neil McGovern wrote: On Thu, Mar 27, 2014 at 01:03:31PM -0700, Steve Langasek wrote: Do you think it's appropriate for these organizers to use Debian's name in seeking local sponsorship without consulting the DPL? Sorry for not being clearer, but no. I think that a central repository and/or sponsors team is quite important to ensure that our sponsors aren't being pestered by disparate people. Organisations already find the concept of Debian's distributedness quite hard to grasp, so I think that this contact point would be useful. However, with the example of sprints, then it's certainly useful for local sponsorship to happen. I'd like to ensure it's easy for people to see if some sponsor is being handled by a central team, but that shouldn't bind people to a requirement that all requests go through there - rather that the central team should be kept in the loop. I wouldn't want my employer to offer me the office for a weekend, but then me having to ensure approval happens for Debian to use it. Thanks for the response, and I agree with you that it would be silly to require central approval before $DD's employer could give them the use of the office for the weekend, which is not transmutable into global sponsorship. I'm mostly interested in the question when someone is looking for financial sponsorship. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: All DPL candidates: Debian assets
Hi Neil, On Thu, Mar 27, 2014 at 06:44:24PM +, Neil McGovern wrote: On Fri, Mar 21, 2014 at 04:02:57PM +, Lars Wirzenius wrote: On Thu, Mar 20, 2014 at 10:44:07PM +0100, Neil McGovern wrote: At the moment, in just SPI, we have 100k USD awaiting being spent. As an indication, that’s enough for a DebConf without any sponsors! Our donations should be spent. Be that better porter boxes, or a better backup service, or simply making sure our core machines are replaced regularly. Lucas and Neil, what are your opinions on spending some of that money on frequent springs, e.g., for bug fixing? I'm a lot more relaxed than Lucas about spending our excess money in this way. If there's an organised BSP or event, then applying to Debian through the DPL is very useful. However, I'd expect the organisers of the BSP/sprint/whatever to seek local sponsorship as well if possible. Do you think it's appropriate for these organizers to use Debian's name in seeking local sponsorship without consulting the DPL? I ask because in many cases, our local sponsors are the same as our global sponsors. From a Debian fundraising POV, I am concerned about the idea of individual DDs soliciting contributions to Debian in an uncoordinated manner, that could jeopardize our future ability to secure sponsorship from them at the global level. There have indeed been several events in the past year organized at the local/regional level that were sponsored by companies that are regular sponsors of DebConf, and while there is no evidence that this has negatively impacted DebConf fundraising (it's possible that these sponsors have increased their overall sponsorship because of the local angle, rather than it taking away from money they would've given to Debian globally), I think DDs soliciting sponsorship in Debian's name is something that should only be done with central approval. What are your thoughts on how this should be handled? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: All DPL candidates: Debian assets
Hi Lucas, Since I am one of the local organizers this year for DebConf, which is Debian's single largest annual expense; and in light of the ongoing discussion you and I are having about DebConf budgeting; it should be no surprise that I have opinions on the question of Debian asset management. ;) So I'm going to pile on this thread with some questions to both candidates about their view of the DPL's role in responsibly managing Debian funds. On Fri, Mar 21, 2014 at 05:37:04PM +0100, Lucas Nussbaum wrote: On 20/03/14 at 22:44 +0100, Neil McGovern wrote: I don’t think there’s an “if” here. Ever since I was secretary of SPI, I’ve been concerned about the amount of money that Debian has earmarked. Again, I disagree with Lucas here - I don’t think that saving donors money is a good plan, our donators expect their donations to be spent to progress the project. At the moment, in just SPI, we have 100k USD awaiting being spent. As an indication, that’s enough for a DebConf without any sponsors! Our donations should be spent. Be that better porter boxes, or a better backup service, or simply making sure our core machines are replaced regularly. I would put it differently: in SPI, we have ~$100k. That's barely enough for a DebConf for which fundraising would mostly fail, or for which many unexpected expenses would need to be made! (the amount of sponsorship raised for DC13 was ~ $160k; the deficit for DC10 was $50k despite $90k of fundraising) (To Lucas) Why should Debian need to hold a reserve with its TOs to fully fund a DebConf for which fundraising has failed? I believe the operating principle is that the DebConf organization should never spend money that it doesn't already have - i.e., never more than the sum of confirmed DebConf sponsorship plus money from Debian's general fund that the DPL has approved (with the possibility, but not the guarantee, that it will be returned at the end of the conference). Do you disagree with this principle? If so - why, and what are the criteria you would use to decide a DebConf has failed at fundraising and dip into these reserves? If not - why does Debian need to worry about reserves to cover DebConf? (To both) What kinds of unexpected expenses do you think Debian should keep funds available to cover? What do you think is the appropriate level of cash reserves for the project to hold, and why? We need some amount of savings to care for all the unexpected problems that could happen, and at the same time, we need to spend money where needed to support Debian's goals. The really hard problem is to find a good balance between saving money for the unexpected, and spending more money. We need to be careful with that, and build a good understanding of Debian's historical needs so that we can spend more money if needed without jeopardizing the future. So, yeah, it seems that Neil and I disagree on that, because I don't think that it's as simple as 'our donations should be spent'. (To both) Management of Debian's assets is one of the key duties of the DPL. What principles guide you in deciding how to balance the use of Debian's assets (infrastructure, DebConf, other Debian sprints, other expenses)? If elected, what will you do to ensure transparency to the project about how Debian money is being spent, and how these expenses affect our overall cash reserves? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: what should the DFSG apply to?
On Sun, Mar 23, 2014 at 08:40:52AM +0100, Wouter Verhelst wrote: My point is that that GR was highly divisive, and had far-reaching repercussions beyond what the original proposers had expected. We have a consensus now that everything in Debian should be free, even those parts that some don't consider to be software. While some parts of the DFSG could be interpreted differently when viewed in isolation, as part of the Social Contract and with the context it is clear that this is not meant. We do not have a consensus that each of the points of the DFSG is meant to apply equally to all works in Debian. I voted for the GR that amended the SC, and it was never my intent that non-program works be held to the standard that source must be included in the package. The current ftp team policy exceeds the letter of the DFSG, and should be corrected, probably by a GR to clarify the text. But I have no idea why this question is being addressed to the DPL candidates. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: The Code of Conduct needs specifics
Hi Solveig, On Mon, Mar 24, 2014 at 02:31:54AM +, Solveig wrote: [short version: The Code of Conduct should be vastly rewritten. Yes, *before* voting on it] A few days ago, i saw the proposal for a Code of Conduct. First I was very glad, then I read it and was perplexed. I made some research, which confirmed my suspicion: the Code of Conduct that is actually proposed is in the best case useless. You might say it's better than nothing, but actually it's not: that's giving yourself good conscience without really improving the situation. Oh yes, we have a CoC. It helps in no way to avoid problems, but you can't tell us to improve the situation because hey, we have a CoC. Also, it was such a huge effort to make this happen, we won't put more anytime soon and we would be sad to hear it doesn't work, so shut up. I think if you do something, do it right. Lots of feminists, who work on these questions since years, collectively, and are concerned by the problem, have documented not only *why* have a CoC, but also *how* - not following their advice is silly and wrong. https://en.wikipedia.org/wiki/Not_invented_here While it's worth discussing how the code of conduct can be improved, this is a wholly unscientific appeal to authority. There may happen to be a group that has worked on CoC questions, but where's the evidence that their answer is *right*? Where is the evidence that their approach to CoCs results in materially better outcomes? My interest in seeing a CoC for Debian is not in banning a set of specifically enumerated behaviors, but to improve the overall quality of discourse on Debian mailing lists. Defining the line beyond which behavior will be censured can only ever give you a minimum threshold for behavior, it will never help raise it any higher than that. To inspire people to be their better selves requires a list of dos, not a list of do nots. The latter is something that the listmasters can already handle under their existing authority; it's the former that warrants the Debian project taking a position as a whole. In considering the question of a code of conduct, I personally take my cue from the one in Ubuntu: an affirmative statement of values the community holds itself accountable to. When I began working for Canonical and became involved in the Ubuntu community, I agreed to the Ubuntu CoC, which meant holding myself to a higher standard in my engagements not only with the Ubuntu community, but with the broader Free Software family - including Debian. As a result, I noticed a change for the better in my behavior on Debian mailing lists. The behavior that I see on Debian lists these days that I think is problematic would be unambiguously contrary to such a CoC, and this really has nothing to do with, e.g., sexist jokes. Sexist jokes are bad and should not be allowed on the Debian lists; but I also don't think that's the problem that we need to be worried about solving by ratifying a CoC. So, an Unacceptable Behavior section should be added. Personally, I would not be opposed to the addition of such a section; but I still think this is secondary to the main purpose of ratifying a CoC. I can write specific amendments, if somebody is willing to sponsor them :) If you would like to see change here, I think this is probably the best way forward. Without specific text to consider, this is likely to result in an open-ended discussion that doesn't get us to a usable amendment in time. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Debian Project Leader Elections 2014: Call for nominations
On Mon, Mar 10, 2014 at 10:51:36AM +, Jonathan Andrew Upton wrote: Hi, Kurt, I hereby nominate Neil McGovern as a candidate for the 2014 DPL Election. DPL candidates are self-nominated from among the pool of Debian Developers. You cannot nominate Neil for DPL. :) http://www.debian.org/devel/constitution#item-5 -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Proposal - preserve freedom of choice of init systems
On Sun, Mar 02, 2014 at 07:15:09PM +, Sune Vuorela wrote: Logind requires systemd. This is false, and therefore the rest of the question is irrelevant. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Proposal - preserve freedom of choice of init systems
On Sun, Mar 02, 2014 at 08:22:14PM +, Matthew Vernon wrote: Second, Matthew's proposal explicitly doesn't change the TC decision, so I'm not even sure what you think would be aborted here. It wouldn't have any effect on the choice of default. It dictates in a top-down manner to individual developers how to do their work and undermines the flexibility of Debian contributors in ways that I think are unnecessary and a little condescending, and requires work be done without identifying anyone who is going to do the work, which is why I voted against it. But it's not some sort of end-run around the previous decision. The previous decision does say that it is replaced completely by the text of such a position statement and I do note that the proposed GR does, very carefully, not refer to systemd as the default. It makes for a clumsier construction, which when combined with the level of legal-ish arguments being made here, makes me suspicious. Please don't read anything into the lack of mentioning systemd in my GR proposal. I in no way intend to undermine their decision that systemd is the default linux init for jessie. I thought The TC's decision on the default init system for Linux in jessie stands undisturbed. was clear enough. Given the ambiguity about whether this GR vacates the earlier TC decision, I think it would be best to simply include in your GR text a statement that The Debian project reaffirms the decision of the TC to make systemd the default init system for jessie. (Then I suppose if people don't actually want to reaffirm this, they can propose amendments to the contrary; but AFAICS it's better to be explicit here.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Proposal - preserve freedom of choice of init systems
On Sun, Mar 02, 2014 at 01:53:06PM -0800, NoTo CTTE wrote: Four people get to decide what operating system debian is. Four. And we have to accept that for some reason. Debian developers don't have to accept it; they can pass a GR choosing a different default if they think that systemd is the wrong choice. *You*, OTOH, have to accept it because you're an anonymous troll whose words carry absolutely zero weight with the Debian community. You are this guy: http://www.penny-arcade.com/comic/2004/03/19 And that guy doesn't get a say in Debian's decisions. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: GR: Selecting the default init system for Debian
On Thu, Jan 23, 2014 at 08:58:08AM +0900, Charles Plessy wrote: Le Sun, Jan 19, 2014 at 01:01:44AM +0100, Guillem Jover a écrit : I think that forcing a decision through the TC at this time was very premature and inappropriate, because I don't think enough effort had been made to reach consensus (failing §6.3(6)) I agree that calling the TC was premature. We have a default init system that has the Essential flag, and it is impossible to switch to alternatives without going through a very strong warning. Factually incorrect. The sysvinit package in unstable has been fixed to depend on sysvinit-core | upstart | systemd-sysv, allowing users to switch between init systems without removing an essential package. In my understanding, to have GNOME 3.10 in Debian, we need to work around this difficulty. Not true, on multiple axes. In that sense, the call to the TC was premature: we should remove obstacles for change, and only top-down decide when some ways are incompatible in a way that is affecting a large number of users. If one day it is not possible to have Desktop manager A and Desktop manager B installed on the same machine, the solution may be simply to call this unsupported unless there is a significant demand for this feature. A decision needs to be made about the default init system. Like other questions of defaults, it's not clearly the remit of any particular maintainer or maintenance team in Debian. Such things tend to be decided by fiat by the installer team, but in this case that's not possible; the presence of the Essential flag on the sysvinit package historically means that the change of default must be made by coordination with the sysvinit maintainers. If you want to avoid a TC decision, I suppose that as a regular committer to the sysvinit package I could just take it upon myself to set upstart as the default. But I thought that it might be better to have a slightly less unilateral decision-making approach. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: GR: Selecting the default init system for Debian
Hi Guillem, On Sun, Jan 19, 2014 at 01:01:44AM +0100, Guillem Jover wrote: Moreover, none of the proponents of alternative init system seem to have expended much energy in seeking wide deployment of their solutions within Debian (or, with the exception of upstart, even updating the policy manual) before this binding ruling was sought. Setting aside the question of whether the TC should take this decision (which there's no point in discussing, as it's clearly your right to bring a GR if you disagree on this), can I ask how you arrived at the conclusion that not much energy has been expended on upstart in Debian? I've actually spent quite a lot of time and energy on getting upstart, and other base system packages, into a state that users should be able to switch from sysvinit to upstart without regressions. That means getting the ifupdown integration in place, making sure lvm and network filesystems work at boot, ensuring transparent handling of startpar dependencies on scripts that are shadowed by native upstart jobs, etc. It does *not* mean doing very much work on pushing native upstart jobs to maintainers of leaf packages; that should be secondary to getting a complete and correct base into Debian. But we certainly are at the point today where such jobs can be implemented more widely in packages. If you have a different standard for seeking wide deployment, I'm interested to know what it is. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Norman Petry and I (Ossipoff) recommended CSSD, but Schwartz Woodall is a better voting system for Debian
Hi Michael, On Thu, May 09, 2013 at 04:11:58PM -0400, Michael Ossipoff wrote: [quote] However this seems quite a risky strategy by the B voters. The situation seems contrived and unlikely to arise in practice. [/quote] But what if the B voters know for a fact that the A voters are completely conscientious, responsible, and co-operative, and that the A voters are sure to rank B over C? Sure, I agree that there are a number of good reaons why the chicken dilemma needn't be a problem. But, even if it isn't a full-fledged problem, it remains a _nuisance_. For me to consider this a nuisance, I would have to see that there is a practical case where a rational group of voters might use this strategy to sway the election in their direction. Clearly, there are cases where CSSD would reward strategic voting *if* a voting bloc had perfect knowledge of how everyone else would vote. But is that realistic? In your original scenario, the preferences are: 99: ABC 2: BAC 100: C(A=B) But how are the B voters to know this with certainty? Even one voter preferring ACB (or at least, voting that way) is sufficient to undermine this strategy, because instead of stealing the vote for B, they're suddenly throwing the vote to C, which is the outcome they strongly want to avoid: 98: AB 1: ACB 2: B 100: C C defeats A, 10099; A defeats B, 992; C defeats B, 101100; so C is the winner. The reason we care about these properties of voting systems is that we want to avoid rewarding strategic voting. I posit that a strategy that allows for a margin of error of 1% in the attackers' understanding of how all other voters will vote before it yields a pathological outcome instead is not a very rewarding strategy at all. All other things being equal, it would of course be better to address the chicken dilemma. However, you bear the burden of demonstrating that all other things actually are equal. The method you propose has been evaluated with respect to a couple of important criteria (the Mutual Majority Criterion and the Condorcet Criterion); but what about other criteria that CSSD satisfies? There are lots of criteria that are interesting to students of voting, and it's well known that some of them are mutually exclusive; before making any changes to our voting system, we should understand the consequences fully, not just with regards to a couple of handpicked criteria that are superficially the most important. Where can we find public, third-party review and analysis of the method you propose (which seems to be a hybrid of other methods - so I'm not sure if it can properly be called Schwartz Woodall or not?)? Since the voting algorithm is enshrined in the Debian constitution, the cost of changing it is high; the burden of proof when arguing for a change is therefore high as well. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Norman Petry and I (Ossipoff) recommended CSSD, but Schwartz Woodall is a better voting system for Debian
On Tue, May 14, 2013 at 05:22:43PM -0500, Steve Langasek wrote: Where can we find public, third-party review and analysis of the method you propose (which seems to be a hybrid of other methods - so I'm not sure if it can properly be called Schwartz Woodall or not?)? Whoops, sorry - I see on rereading the initial message that Schwartz Woodall is the name given to this precise hybrid method. Otherwise, my questions stand :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Norman Petry and I (Ossipoff) recommended CSSD, but Schwartz Woodall is a better voting system for Debian
that the chicken dilemma is the practical problem that IRV advocates argue it is. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: DPL 2013: Lats call for votes
On Sat, Apr 13, 2013 at 10:29:06AM +0200, Debian Project Secretary - Kurt Roeckx wrote: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 8367b943-96ac-4530-afbd-529da5fc4fd5 [ 7 ] Choice 1: Gergely Nagy [ 3 ] Choice 2: Moray Allan [ Q ] Choice 3: Lucas Nussbaum [ ə ] Choice 4: None Of The Above - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- signature.asc Description: Digital signature
Re: [all candidates] Return to the desert island (cont.)
On Wed, Mar 20, 2013 at 02:07:40AM -0400, Michael Gilbert wrote: On Tue, Mar 19, 2013 at 7:46 PM, Steve Langasek wrote: On Tue, Mar 19, 2013 at 11:39:29PM +0100, Jérémy Bobbio wrote: 3. One test I've been taught to use to reason about free software is the Desert Island test [2] which starts by: Imagine a castaway on a desert island with a solar-powered computer. Obviously, software that are only frontends to unreproducible “cloud” services do not pass the desert island test. This is a mischaracterization of the Desert Island test as it was formulated on debian-legal. The Desert Island test is about whether a user can *comply with the license* of the software on a desert island when they have no contact with the outside world. That the software may not be *useful* to them on a desert island is a separate question, and applies to many sorts of software, not just those used for connecting to particular services over the Internet. Then again, this is a misinterpretation of the fundamental question Jeremy has attempted to pose. I am only addressing the factually incorrect interpretation of the Desert Island test, because such inaccuracies, if allowed to stand uncorrected, have a nasty habit of spreading. So no, I did not misinterpret his question - but as I am not a candidate, my thoughts on that question are out of scope for this discussion. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [all candidates] Return to the desert island (cont.)
On Tue, Mar 19, 2013 at 11:39:29PM +0100, Jérémy Bobbio wrote: 3. One test I've been taught to use to reason about free software is the Desert Island test [2] which starts by: Imagine a castaway on a desert island with a solar-powered computer. Obviously, software that are only frontends to unreproducible “cloud” services do not pass the desert island test. This is a mischaracterization of the Desert Island test as it was formulated on debian-legal. The Desert Island test is about whether a user can *comply with the license* of the software on a desert island when they have no contact with the outside world. That the software may not be *useful* to them on a desert island is a separate question, and applies to many sorts of software, not just those used for connecting to particular services over the Internet. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [all candidates] on distribution-wide changes and scalability
On Thu, Mar 14, 2013 at 05:55:33PM +0100, Stefano Zacchiroli wrote: - on the judgement spectrum between there is no inertia in Debian and that's good and there is a lot of inertia in Debian and that's bad, where would you put yourself? Is this a trick question? Where is there is a lot of inertia in Debian and that's good on this spectrum? ;-) (Being slow to implement technical consensus is a bad thing; but inertia that prevents changes from being foisted on the project before there *is* consensus is a *good* thing.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: (maybe) constitutional amendment: clarification of section 5.1.5
Hi Wouter, On Sat, May 19, 2012 at 08:55:39PM +0200, Wouter Verhelst wrote: When I read the constitution so many years ago for the first time, there were some things that stuck, and others that didn't. One of the things that stuck was a particular power of the DPL which I hadn't seen used in, like, forever. And when I wanted to send a private mail to our current DPL about that subject, I noticed that my reading of the constitution may have been in error. Section 3.1.2 of the constitution reads as follows: [...An individual developer may...] 2. Propose or sponsor draft General Resolutions whereas section 5.1.5 reads as follows: [...The project leader may...] 5. Propose draft General Resolutions and amendments. I had always, probably incorrectly, interpreted the lack of the words or sponsor in that sentence as meaning that a GR proposal from the project leader doesn't actually require sponsors. I'm quite certain that's the correct interpretation. Why do you now think this interpretation is incorrect? That interpretation probably would have made sense if the word draft wasn't in that sentence: in that case, non-DPL DD's could propose draft GR statements, which would become proposed GR statements upon acquiring enough seconds, and GR statements once they had been voted upon. Had it not used draft, then the Project Leader could bypass the draft phase in that order. But at any rate, that's not what it says. A draft GR is one that is still in the process of being brought to a vote. The DPL has the power to put a draft up for consideration and start the clock on the amendment process, without requiring any seconds to do so. Likewise, under the Standard Resolution Procedure (Appx. A), the DPL can propose an amendment to someone else's resolution which becomes a formal amendment with no seconds required, and it can be accepted by the drafter of the original proposal or rejected and immediately become an additional ballot option. Having thought about it this way for years (without ever having seen it happen, of course), I do believe this is actually not that bad an idea, as it would allow a DPL to fast-track a vote on an important issue: recall that any accepted amendment resets the discussion period, as per A.2.4; to avoid unnecessary delay in the procedure, the DPL could use that power to bring an amendment on the ballot immediately, without having to wait a few days for more formal seconds and thereby risk what I'll call accidental filibustering. Bearing in mind that the meaning of accepted amendment is an amendment *that's accepted by the author of the original proposal* and is thus incorporated into the first ballot option. Rejected amendments, i.e. those that result in additional ballot options, do not reset the discussion period. If people do not think I'm crazy, I'd like to propose a formal amendment to make this reading the official one. I don't understand what should need amending here, as your reading appears to already be the correct one (and, indeed, the only one that makes any sense given the language in the constitution). If the current language is unclear, I don't mind trying to clarify it... but I think that could easily backfire. :) At any rate, ignoring what may be no more than a silly brain fart on my end, there's still a bit in there which could use some clarification: as written currently, and ignoring the procedure under A.1, it would appear as if non-DPL developers don't actually have the right to propose amendments. This is obviously in error, and I think it wouldn't hurt to fix that. This is currently covered in 4.2. 1. 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. Adjusting 3.1.2 to add or amendments would be correct and may be less confusing, but is not strictly required. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20120519235756.ga27...@virgil.dodds.net
Re: (maybe) constitutional amendment: clarification of section 5.1.5
On Sun, May 20, 2012 at 02:17:49AM +0200, Kurt Roeckx wrote: On Sat, May 19, 2012 at 04:57:56PM -0700, Steve Langasek wrote: Rejected amendments, i.e. those that result in additional ballot options, do not reset the discussion period. I think they do reset the discussion period when they get accepted (have enough seconds), but I would need to re-read that to confirm it. Please re-read - this is not what accepted means in the context of an amendment :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Call for vote - Diversity statement for the Debian Project
On Tue, May 15, 2012 at 11:34:42PM +0200, Francesca Ciceri wrote: A corresponding ballot might look like the following: --- [ ] Choice 1: Welcome everyone [ ] Choice 2: Further discussion --- I find the juxtaposition of these ballot options absolutely hilarious. Nicely done. :-) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Call for vote - Diversity statement for the Debian Project
On Tue, May 15, 2012 at 11:34:42PM +0200, Francesca Ciceri wrote: A corresponding ballot might look like the following: --- [ ] Choice 1: Welcome everyone [ ] Choice 2: Further discussion --- BTW, while I think presenting some people in the project with this set of choices would be entertaining, a more neutral way to word the first ballot option might be: Ratify proposed diversity statement ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [Draft] GR: diversity statement for the Debian Project
On Mon, May 07, 2012 at 08:05:33PM +0200, Francesca Ciceri wrote: I agree that this should go out. Just, we have our community twice in the text. punAny linguistic expertise with us we could possibly welcome?/pun LOL Anyway, it sounds strange enough to me to suggest substituting the first occurrence with just us. And, since we also want new contributors to also interact constructively between themselves, and since to me it is somewhat redundant in the first place, I would even feel inclined to remove the with our community. I'm not sure about removing the with our community, but as this is a style problem (and not a content one) I'd postpone the discussion on it (asking for proofread on -l10n-english) after the vote. I can't agree with this. The wording of position statements matters - what we ratify should be posted word for word on the website. But I also think the crowdsourced review on debian-project has already been more than sufficient and don't think there's any point in further proofreading on -l10n-english. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [Draft] GR: diversity statement for the Debian Project
On Thu, May 03, 2012 at 12:32:03AM +0200, Francesca Ciceri wrote: DRAFT TO BE VOTED STARTS HERE The Debian Project welcomes and encourages participation by everyone. It doesn't matter how you identify yourself or how others perceive you: we welcome you. We welcome contributions from everyone as long as they interact constructively with our community. While much of the work for our project is technical in nature, we value and encourage contributions from those with expertise in other areas, and welcome them into our community. DRAFT TO BE VOTED ENDS HERE Seconded. I know you haven't called for seconds yet, but I don't see any reason to wait when this has already reached broad consensus on debian-project. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Standardization, large scale changes, innovations
On Thu, Apr 01, 2010 at 05:15:38AM -0700, Manoj Srivastava wrote: What about peer review of the packages? My *peers* have no problems dealing with the build system, IMO. As long as you tautologically define your *peers* as the set of people willing to tolerate the gratuitous overhead of learning an idiosyncratic build system when they could be getting on with the real work of fixing bugs instead, yes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Question to all candidates: How would you enforce Debian Community Guidelines?
On Sat, Mar 27, 2010 at 06:47:13PM +0100, Wouter Verhelst wrote: However, as one of my initial actions as DPL, I do intend to submit a post to debian-devel-announce with a set of guidelines for people to follow when flamewars happen (and when they don't, in order to avoid them). Why is sending such a mail conditional on you being elected DPL? How would the content of this mail differ from such a mail if you sent it as non-DPL, and why? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Question to all candidates: How would you enforce Debian Community Guidelines?
On Sun, Mar 28, 2010 at 01:40:44AM +0100, Wouter Verhelst wrote: On Sat, Mar 27, 2010 at 05:26:36PM -0700, Steve Langasek wrote: On Sat, Mar 27, 2010 at 06:47:13PM +0100, Wouter Verhelst wrote: However, as one of my initial actions as DPL, I do intend to submit a post to debian-devel-announce with a set of guidelines for people to follow when flamewars happen (and when they don't, in order to avoid them). Why is sending such a mail conditional on you being elected DPL? How would the content of this mail differ from such a mail if you sent it as non-DPL, and why? Hi, I'm J. Random Developer, and I encourage all of you to abide by these rules vs Hi, I'm the DPL, and I encourage all of you to abide by these rules I don't think the former would work very well; but I believe the latter could. I don't think either would work very well. I could be mistaken, but I think that would be unfortunate, because that would only reinforce the idea of doing what the DPL says because he's the DPL instead of because he's made a persuasive case. So the only change you would make to the content when sending such a message as DPL vs. a normal developer would be Hi, I'm the DPL? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Question to the candidates
As a developer, how do you embody the spirit and culture that has made Debian a great operating system? If elected DPL, how will you inspire the same in others? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Q for the Candidates: How many users?
On Mon, Mar 22, 2010 at 02:27:23PM +0100, Bernd Zeimetz wrote: * www.debian.org/social_contract says Debian's priorities are our users and free software, * popcon.debian.org currently reports 91,523 submissions, * popcon.ubuntu.com currently reports 1,493,440 submissions, and * that this is something of a trick question, That results in a different question for me: Does Ubuntu enforce the usage of pocon, God, no. and should Debian do so, too? God, no. :) On Mon, Mar 22, 2010 at 09:50:55PM +0100, Mike Hommey wrote: OTOH, if popcon is mandatory on Ubuntu, it means the popcon result for Ubuntu more or less reflects the number of Ubuntu users. It also means that, according to your estimate of the number of Debian users, Ubuntu is not as far ahead as at least I would have thought. http://lxer.com/module/newswire/view/123481/index.html -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Question to all candidates: financing of development
On Tue, Mar 16, 2010 at 12:12:02AM +0100, Wouter Verhelst wrote: I also don't think it is a bad thing, in principle, if Debian were to pay people to work on Debian. However, it is generally a bad idea if some cabal were to select who could get Debian monies and who couldn't; I believe that is the main problem that existed with the Dunk-Tank story. The use of Debian money for Dunc Tank was only present in a first draft that was discarded in the face of opposition within the project. Does the final funding solution that was implemented also fall under this cabal description, in your opinion? If so, how do you distinguish this from other DDs who are privately funded to work on Debian? If not, how do you reconcile this with the ongoing community resistance to Dunc Tank even after it was decoupled from Debian money? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20100315235320.gb21...@dario.dodds.net
Re: Draft vote on constitutional issues
On Sat, May 02, 2009 at 12:32:26AM +0200, Luk Claes wrote: Option 1 - No Supermajority We do not believe that we should require anything more than a simple majority for any changes to the constitution or foundation documents. - replace Constitution 4.1 point 2 with Amend this constitution - in Constitution 4.1 point 5, point 3, remove A Foundation Document requires a 3:1 majority for its supersession. This option amends the constitution and hence requires a 3:1 majority. I would be very surprised if this option would get enough seconds if you would propose it. Hmm, I wouldn't second this in its present form because I don't see any reason to change the supermajority requirement for amending the constitution - I don't think anyone has ever disputed the meaning of this requirement, and it's been there since well before the Foundation Documents supermajority requirement was instituted. But I would strongly consider seconding (as one option among many) a proposal to remove the 3:1 supermajority requirement for amending Foundation Documents, because I think the most recent fiasco has given cause to reevaluate the reasons we required a supermajority in the first place. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Draft vote on constitutional issues
On Sun, May 10, 2009 at 01:12:27PM +0100, Matthew Johnson wrote: On Sun May 10 04:13, Steve Langasek wrote: Hmm, I wouldn't second this in its present form because I don't see any reason to change the supermajority requirement for amending the constitution - I don't think anyone has ever disputed the meaning of this requirement, and it's been there since well before the Foundation Documents supermajority requirement was instituted. But I would strongly consider seconding (as one option among many) a proposal to remove the 3:1 supermajority requirement for amending Foundation Documents, because I think the most recent fiasco has given cause to reevaluate the reasons we required a supermajority in the first place. Yes, I was wondering if that was a good idea. Do you want to draft that? If one of the other options gets enough seconds to become a formal GR proposal, I would consider drafting a suitable amendment. I'm not going to spend the time on it when there isn't yet a GR on the table. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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, May 01, 2009 at 11:54:15PM +0100, Matthew Johnson wrote: On Sat May 02 00:52, Luk Claes wrote: It would be a clear indication that the foundation document should get an update or that the postition statement should get dropped again. I think Manoj's point is that if voting some option X (a position statement in conflict with an FD) means that we have to vote to change the FD or drop X, then why wasn't X a vote to change the FD in the first place? Surely we don't need a vote just to then have another vote... No one has the authority to declare, a priori, for the entire project, that a given position statement is in conflict with a FD. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Amendment] Reaffirm current requirements for GR sponsoring
On Thu, Mar 26, 2009 at 01:26:33PM +0100, Frans Pop wrote: Are you promoting the practice of voting by I haven't got a clue what this vote is about, but my friend X is supporting option C so I'll vote for that here? I know it happens, but I'd prefer to make that harder rather than facilitating it. I'm saying it happens, and I'd rather not have a vote go the wrong way because the only names the voters recognized were on the wrong side of the issue. :P -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Amendment] Reaffirm current requirements for GR sponsoring
On Thu, Mar 26, 2009 at 02:12:17AM +0100, Frans Pop wrote: Getting seconds is not a vote. It's a low-level check that there is minimum support for an opinion. It's also the most reliable way for a developer to issue a statement of support that will be seen by voters prior to the vote. Many voters don't follow debian-vote and won't follow the pro/con discussions in detail, but the debian-devel-announce mail links to the vote.d.o webpage that lists all the seconds right next to the amendment text. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Amendment] Reaffirm current requirements for GR sponsoring
On Tue, Mar 24, 2009 at 04:10:49PM -0700, Lucas Nussbaum wrote: PROPOSAL START = General Resolutions are an important framework within the Debian Project. While over those years, some problems have arised during the discussion and/or voting of some resolutions, there is no evidence that changing the number of sponsors (seconds) for GR proposals or amendments will help solve those problems. Instead, by making it harder to propose general resolutions or amendments, it might make it harder to improve imperfect resolutions, or to add valuable options to a ballot. Therefore the Debian project reaffirms the current requirements for the sponsoring (seconding) of GR proposals or amendments, and for overruling of delegates. = PROPOSAL END Seconded. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [Amendment] Reaffirm current requirements for GR sponsoring
On Tue, Mar 24, 2009 at 04:49:54PM -0700, Lucas Nussbaum wrote: Since nobody sponsored it yet, Actually, someone did, but: I'm amending it to fix: s/arised/arisen/ s/those years/the years/ Under A.1.6, you can fix spelling and grammar without having to re-solicit seconds. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Amendment] Reaffirm the GR process
On Mon, Mar 23, 2009 at 11:42:40PM +0100, Bill Allombert wrote: Hello developers, I am hereby proposing the amendement below to the General resolution entitled Enhance requirements for General resolutions. PROPOSAL START General Resolutions are an important framework within the Debian Project, which have served us well since the first GR vote in 2003, with 804 developers, nearly has much as today slightly over 1000 developers. I disagree that GRs have served us well. I found developers were much more likely to seek consensus during the period when the GR procedure was unavailable, and that having a mechanism for forcing a majority view on people has only served to draw out the tendency to do exactly that. But I also don't agree that raising the number of seconds required is an appropriate way to handle this. So I am seconding none of these proposals. Therefore the Debian project reaffirms its attachement to the constitution and the current General Resolutions process. s/attachement/attachment/ -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Sun, Mar 22, 2009 at 11:28:56AM +0100, Patrick Schoenfeld wrote: Well, because it is in line with the questions which they have been asked and its both a good chance to see weither they stand on a similar point as I do and to see weither anyone is interested in the idea at all. Surely I intend to propose it to the larger body once its more then a rough idea. I expressly refrained to answer your mail because it targetted the DPL candidate but IMO it's one those false good ideas until you make it a reality. I'm all for a team of many people improving the base packages, so find those people and start triaging and writing patches _together_ with the actual maintainers. Well, some time back I wrote some patches for coreutils. Unfortunately they are not yet integrated, but thats not the fault of the maintainer. However I think it could help if the project decides that this is a good idea and (if needed) can overrrule single maintainers. There are existing procedures for overruling individual maintainers - i.e., appealing to the Technical Committee. If you think an override is needed, you might try the existing process before deciding that we need an entirely new one? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Sat, Mar 21, 2009 at 01:43:16PM +0100, Patrick Schoenfeld wrote: Some of these packages are very well maintained and others.. well, bug numbers sometimes speak for themselves. For these packages we have that cool text on the PTS pages: The package is of priority standard or higher, you should really find some co-maintainers. which brought me on this at all. What I thought about when I read that is: HaHaHa, we are kidding on us own, because we recommend something to us, what should actually be the default (for this type of packages). Thats why I thought it would eventually be a good idea to form a core team, meaning a team of a bunch of people (10-20?), with wide-spread knowledge and known to have enough free time (e.g. people who have 50 packages and aren't able to keep up with the bug reports in their own packages wouldn't qualify) that gets the job to (co-)maintain all these packages that are very important to us. It doesn't mean that the existing maintainers are taken away the packages, because they could still stay the maintainers, but obviously some of these packages are not easily maintainable by one person. What do you think about such a proposal? Why are you asking the DPL candidates what they think of this proposal, instead of proposing it to the developers? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: Do not require listing of copyright holders
On Sat, Mar 21, 2009 at 09:38:04PM +, Mark Hymers wrote: I've therefore asked the DPL to get us legal advice on the minimum copyright information we should ship in debian/copyright. Once we get this, I propose we amend policy to be crystal clear about what we need (basically, what we can get away with[0]) and then all carry on. I think this needs to be a two-part question to the lawyer: what does copyright law require, and what does the GPLv3 require. I believe they are not the same. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Constitutional issues in the wake of Lenny
On Sun, Mar 15, 2009 at 08:49:51AM +, Matthew Johnson wrote: Maybe I just see GRs as a last resort where we really really need a definitive answer. Except they aren't; they're used any time six developers *think* we need a definitive answer, which is not the same thing. Certainly after we've gone through the whole process I'd like all that effort to have resulted in a solution everyone has to follow... Requiring supermajorities doesn't ensure that. What says that the outcome won't be Further discussion instead? Then you've gone to all that effort to result in no solution at all. In any case, the desire to minimize the number of GR round-trips doesn't justify preventing other DDs from proposing position statements if they choose to, even when you consider those position statements to contradict the Foundation Documents. You *always* have the option of proposing an amendment that explicitly modifies the Foundation Document instead. Maybe you'll persuade the proposer to accept the amendment; maybe you'll end up on the ballot as a separate option and the developers will agree to modify the Foundation Document; or maybe your option will fail to reach supermajority, and we'll instead have a non-binding position statement. Why shouldn't all of these options be open to developers? Even if you don't give developers the option of formally ratifying position statements that interpret the Foundation Documents, developers are still going to do their own interpreting of these documents, and more often than not they're going to assume that the rest of the project agrees with them. So I don't see any way that permitting such position statements is *worse* than having Further Discussion win. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian Project Leader Election 2009: Final call for nominations.
On Sat, Mar 07, 2009 at 02:18:03PM +0100, Wouter Verhelst wrote: You mean I can nominate someone else? ;-P (suggested phrasing: To be valid, a Debian Developers can send a signed email in which they nominate themselves, to the debian-vote@lists.debian.org lists this nicely avoids gender issues while not having to use single plural idiosynchracies) a Debian Developers? :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian Project Leader Election 2009: Final call for nominations.
On Sat, Mar 07, 2009 at 12:53:10AM +, Per Andersson wrote: On Fri, Mar 6, 2009 at 5:46 PM, Debian Project Secretary secret...@debian.org wrote: To be valid, a Debian Developer needs to send a signed email in which he nominates himself to the debian-vote@lists.debian.org list. Can't women nominate themselves? Clearly the Project Secretary's mail was a clever troll intended to trick our female developers into standing for DPL. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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, Feb 27, 2009 at 02:10:38AM -0800, Don Armstrong wrote: 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. 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? All I see that we get is a measure of how comfortable the candidate is with (English-language) IRC as a medium, which is just not that interesting to me as a factor in deciding who I'm going to vote for as DPL. Is it to other people, or are others getting something else out of this that I'm overlooking? For the last two election cycles, I've ignored the IRC debate completely, and I don't feel that I missed anything. Am I mistaken? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results of the Lenny release GR
On Mon, Jan 12, 2009 at 08:37:06AM +0100, Robert Millan wrote: I know you didn't explicitly request being appointed Secretary; it sort of happened by accident, but you had the opportunity to refuse all the time, so I must take it that you accept it, at least temporarily. This is not true. The constitution specifies that when there is no Secretary, the chair of the Technical Committee serves as Acting Secretary. To refuse the post of Acting Secretary, Bdale would have to step down as TC chair. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results of the Lenny release GR
On Mon, Jan 12, 2009 at 12:42:12AM -0800, Steve Langasek wrote: On Mon, Jan 12, 2009 at 08:37:06AM +0100, Robert Millan wrote: I know you didn't explicitly request being appointed Secretary; it sort of happened by accident, but you had the opportunity to refuse all the time, so I must take it that you accept it, at least temporarily. This is not true. The constitution specifies that when there is no Secretary, the chair of the Technical Committee serves as Acting Secretary. To refuse the post of Acting Secretary, Bdale would have to step down as TC chair. ... furthermore, as TC chair, Bdale is one of only two people in the project who are ineligible to be Secretary. He certainly has not accepted a temporary position as Secretary. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 01:18:43PM +0100, Robert Millan wrote: On Sun, Jan 11, 2009 at 01:06:21PM +0100, Michael Banck wrote: On Sun, Jan 11, 2009 at 08:22:58AM +0100, Robert Millan wrote: You're the Secretary. You're supposed to give answers, not speculation. If the ballot was ambigous, or confusing, it is YOUR responsibility. It has to be said that at least I am taking YOU personally responsable for a lot of why the ballot was ambigous as well, not least to the fact you named your proposal Reaffirm the Social Contract, i.e. SC-trolling the rest of the project not in line with your opinion. I keep hearing this SC is not binding story, as if repeating it lots of times made it true, but fact is that the project already rejected option 4 which is the one that represents this line of reasoning. If you're so serious about it, I challenge you to propose it as a separate vote. I challenge you to do something useful for the project instead of dragging us down with voting nonsense. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Purpose of the Constitution and the Foundation Documents
On Tue, Jan 06, 2009 at 03:45:59AM +, Ian Jackson wrote: This leaves us with really four options: A. Explicitly de-entrench the Foundation Documents by repealing Constitution 4.1(5) 1..3 and establishing the Social Contract and DFSG as simple Position Statements according to 4.1(5). B. Explicitly state that the Foundation Documents are to be interpreted by each Developer (and everyone else) for themselves in the context of their own work, eg by inserting 2. including interpreting the Foundation Documents as necessary; in Constitution 3.1. C. Rewrite the foundation documents so that they are clearly comprehensible (rather than vague) and establish an independent legally-minded body to make these decisions. D. Establish (or empower) some kind of interpretation committee, which would have to be elected. I agree with this summary of the available choices. If put to a vote, my vote would certainly be B, A, FD, D, C. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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 Sun, Jan 04, 2009 at 03:55:43PM -0600, Ean Schuessler wrote: - Steve Langasek wrote: Yes, because it's not a supersession of the Foundation Document; it's either a position statement or an override of a decision by a delegate. Position statements are not binding; overrides of delegates can only override decisions that have actually been taken. Either way, if 50%+1 of the project wants to order a project delegate to do something that contradicts the Social Contract, there's no constitutional basis for having the Secretary prevent them from doing so. *The Secretary is an officer of the constitution, not of the Social Contract*. Is now an inappropriate time to start a GR to formally recognize the Social Contract as a component of the constitution? The notion that the Social Contract (our purpose and motivation) is less binding that the Constitution (how we get things done) seems nonsensical in the extreme. I think you misunderstand. I'm bound by the Social Contract because I've *agreed* to uphold it in my Debian work. That makes it more binding, not less; developers don't have to agree to uphold the constitution a a condition of becoming DDs. Trying to prevent 50%+1 of the project from willfully ignoring their promise by writing provisions into the constitution is totally missing the point. Either the people involved are upholding the SC according to *their* understanding of it, in which case no one individual should have the authority to decide for Debian that they're wrong; or they don't care about keeping their promises, so trying to get it written into the constitution is futile. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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
[I see that we're now repeating discussions already had up-list, so this will probably be my last post to this subthread.] On Sat, Jan 03, 2009 at 10:08:47AM -0800, Thomas Bushnell BSG wrote: Nor is it anything short of absurd for the Secretary to declare that a resolution amends a Foundation Document when the actual resolution says nothing of the sort, and the resolution proposer explicitly rejects this interpretation.[1][2][3] So if I propose a resolution that says, say, No uploads made on Tuesday shall be removed from the archive for violations of the DFSG and then I reject the interpretation that this is a supercession of the DFSG, you're saying that such a resolution only requires a simple majority? Yes, because it's not a supersession of the Foundation Document; it's either a position statement or an override of a decision by a delegate. Position statements are not binding; overrides of delegates can only override decisions that have actually been taken. Either way, if 50%+1 of the project wants to order a project delegate to do something that contradicts the Social Contract, there's no constitutional basis for having the Secretary prevent them from doing so. *The Secretary is an officer of the constitution, not of the Social Contract*. If the Secretary believes a resolution is inconsistent with the Social Contract, let him appeal to his fellow developers to keep the promise they each made to uphold the SC. If the resolution passes anyway, let him decide not to implement it in his own work as a developer (either by deciding that the resolution is a non-binding statement, or by stepping aside under 2.1.1 of the constitution). But in no event should he use his position to bias the outcome of the decision-making process itself! The alternative, that passing with a 3:1 supermajority would cause the text of such a resolution to be appended to the DFSG when this was not specified in the resolution itself, is at least as absurd as allowing developers to pass non-binding and possibly nonsensical resolutions. You seem to be saying that what is determinative is the resolution proposer's statement. I find this implausible in the extreme. The Secretary is at least an official who we can hope will be neutral; the resolution proposer is, by definition, not neutral. I'm saying that we should not be trusting in the subjective judgement of either the proposer or the Secretary when deciding that a resolution supersedes a Foundation Document; that supersession is an explicit act. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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, Jan 01, 2009 at 01:49:20PM -0800, Thomas Bushnell BSG wrote: On Wed, 2008-12-31 at 12:01 -0800, Steve Langasek wrote: While I understand the desire to add additional checks and balances in response to figures exercising power in ways we don't approve of, I think the fundamental problem with this latest vote was that the Secretary was asserting a power that was *not* his under the letter of the constitution. Splitting up the constitutional powers doesn't really prevent the Secretary from acting counter to the constitution or counter to project consensus, if they're inclined to do that. When you say he was asserting a power that was not his, what exactly are you saying? I'm having trouble understanding. It is unquestionably the Secretary's job to prepare the ballot and announce the results; this requires the Secretary to determine which options require a 3:1 supermajority. How do you suppose he should go about this task, other than to do his best job? There is no plain English reading of A Foundation Document requires a 3:1 majority for its supersession that implies the secretary should apply a 3:1 majority requirement to resolutions which aren't even intended to override the Foundation Documents, let alone amend them. Nor is it anything short of absurd for the Secretary to declare that a resolution amends a Foundation Document when the actual resolution says nothing of the sort, and the resolution proposer explicitly rejects this interpretation.[1][2][3] Nor, btw, does the final decision on the form of ballot(s) is the Secretary's imply that the Secretary should be ignoring the intent of proposers and seconders in favor of his own definition of a proper resolution when determining the text of a ballot option.[4][5] These are all actions that the Secretary can take by virtue of his position, but none of them are powers given to him by the constitution. Just as a President has the power to suspend habeas corpus by virtue of being commander in chief of a large military, yet this is not a power given to him under the US Constitution. In retrospect, I recognize that I was remiss in not objecting to this pattern of supermajority requirements in earlier votes (even going so far as to endorse them in one case[6]). OTOH, in earlier cases (http://www.debian.org/vote/2006/vote_001, http://www.debian.org/vote/2006/vote_007) the supermajority requirements didn't change the outcome of the votes, whereas they did change the outcome for this vote. I hope that our next Secretary will recognize the importance of not imposing his personal (and contentious) beliefs on the voting process. If they don't recognize this, then I guess it's inevitable that we amend the constitution to limit the Secretary's power. I am distressed that you have this attitude about Manoj's performance, when it is your own decisions as release manager that have also been called into question recently. Would you apply the same standards to yourself? Which decisions are those, exactly? You're aware that I stepped down as Debian release manager after the etch release? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] http://lists.debian.org/debian-vote/2008/11/msg00186.html [2] http://lists.debian.org/debian-vote/2008/11/msg00274.html [3] http://lists.debian.org/debian-vote/2008/11/msg00278.html [4] http://lists.debian.org/debian-vote/2006/09/msg00287.html [5] http://lists.debian.org/debian-vote/2006/09/msg00231.html [6] http://lists.debian.org/debian-vote/2006/09/msg00191.html -- 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 Wed, Dec 24, 2008 at 03:55:40PM +0900, Paul Wise wrote: On Wed, Dec 24, 2008 at 3:15 PM, Steve Langasek vor...@debian.org 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. In addition, it should be fairly easy to add firmware D-I images; hd-media: mount cp ISOs: xorriso (command-line) or isomaster (GUI), or just mount and genisoimage. I wonder, is it somehow possible to generate multi-session ISO images that would let users add in the non-free firmware by mere concatenation? I know you can do multisession DVD+RWs with growisofs, but I have no clue if there are compatibility issues when doing this with raw CDs. netboot: cp At least on archs where the initramfs is fed directly to the tftp server, my understanding is that it should be possible to concatenate multiple cpio archives to provide a single initramfs. (At least, that was supposed to be one of the selling points of initramfs!) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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 Mon, Dec 29, 2008 at 03:52:37PM +0100, Wouter Verhelst wrote: I think that we have made the mistake of giving too much power to one person. While I do not think Manoj willingly abused that power, I do think that this has made it harder for him to retain his objectivity; and that he has lost it over the years, though through no fault of his own. The solution therefore seems obvious: The secretary should no longer be the person who interprets the constitution. Instead, interpretation of the constitution should be given to a small body of trusted developers who only decide on interpretation when explicitly asked to do so. This could be the technical committee, or it could be a new body; but I'd say that leaving interpretation up to one man has now clearly been proven to be a bad idea. While I understand the desire to add additional checks and balances in response to figures exercising power in ways we don't approve of, I think the fundamental problem with this latest vote was that the Secretary was asserting a power that was *not* his under the letter of the constitution. Splitting up the constitutional powers doesn't really prevent the Secretary from acting counter to the constitution or counter to project consensus, if they're inclined to do that. Instead, we have to either have confidence that those who hold positions of power are going to use that power appropriately, or have a system by which we can overrule decisions and/or replace the decision-makers. It's not clear that we can overrule how the Secretary puts together a ballot, short of instructing the Secretary to change the ballot by amending the constitution itself; nor do we have any method of recalling the Secretary, other than by first amending the constitution to allow this. These are both points that I think we should consider revising in the constitution. But really, I think the most important point is that we should have people in positions of power in Debian that the project trusts. It has been quite apparent in this latest vote that Manoj considered himself bound by a higher duty than either the letter of the constitution or the goal of consensus-driven decision-making in Debian. Whether or not this is a fault of his, I for one did not trust Manoj any longer to carry out his constitutional duties as Secretary in a non-partisan manner. I hope that our next Secretary will recognize the importance of not imposing his personal (and contentious) beliefs on the voting process. If they don't recognize this, then I guess it's inevitable that we amend the constitution to limit the Secretary's power. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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, Dec 23, 2008 at 01:07:43PM +0100, Kurt Roeckx wrote: I've been thinking about this proposal for some time, and I probably should have send this some time ago. At least some people seem to have had simular ideas, so I wonder why nobody propsed anything like this. The idea is to create a new section that contains files like firmware images and FPGA data that gets written to the hardware to make it fully functional. It is not meant for drivers that run on the host CPU. The new section should also be available on our CD/DVD images, so that users can just take a CD/DVD and that it works without having to search for the needed firmware and provide it on an other medium to the installer. While I think it would be reasonable to include sourceless firmware on our CDs and DVDs, I don't think this is actually a very good solution to the problem we face: - if they're included on the official Debian images, they need to meet Debian's definition of free. - if the firmware are considered free, then they can live in main. - if the images the firmware is included on aren't Debian images, then there will (presumably) still be demand for pure Debian images, and we don't need to add a new archive section in order to include non-Debian stuff on the images 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. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Supermajority requirements and historical context [Was, Re: First call for votes for the Lenny release GR]
On Mon, Dec 22, 2008 at 08:12:54AM -0600, Ean Schuessler wrote: Condorcet is orthogonal to the issue. It isn't. The US two-party system and resulting political maneuvering are an exploit of FPTP. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Supermajority requirements and historical context [Was, Re: First call for votes for the Lenny release GR]
On Mon, Dec 22, 2008 at 03:55:02PM +0100, Michael Goetze wrote: So, can't this be fixed by just changing the algorithm from drop all options which don't pass majority requirements, then determine the winner to determine the winner, then check whether the winner passes majority requirements? Possibly. The issues surrounding this implementation of supermajority in Condorcet were discussed back in 2002: http://lists.debian.org/debian-vote/2002/11/msg00243.html http://lists.debian.org/debian-vote/2002/11/msg00174.html http://lists.debian.org/debian-vote/2002/11/msg00222.html In reviewing the list archives from that period, it's not immediately clear to me why we ended up with supermajority requirements being handled before calculating the pairwise defeats. At least as late as Dec 7, there were drafts being discussed which had different properties, http://lists.debian.org/debian-vote/2002/12/msg00023.html And it looks like the path to the current algorithm was set with this message on Dec 9: http://lists.debian.org/debian-vote/2002/12/msg00039.html -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Request for ruling re. use of lenny-ignore tags by release team
On Tue, Dec 23, 2008 at 02:00:37AM +0100, Frans Pop wrote: I've decided to ask the DPL and project secretary to rule on this issue based on the following considerations: - the Project Secretary is the guardian of the constitution and thus the correct role to rule on consequences of previous votes; Not really. Being the guardian of the constitution makes the secretary the final authority on interpreting the constitution itself; that doesn't imply any particular power to interpret resolutions. Interpretation of resolutions is best left to those who are expected to implement them. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Supermajority requirements and historical context [Was, Re: First call for votes for the Lenny release GR]
On Sun, Dec 21, 2008 at 03:38:55PM -0600, Ean Schuessler wrote: - Steve Langasek vor...@debian.org wrote: Yes, I agree that supermajority requirements are a bad idea in general. To understand the need for a supermajority all you have to do is look at American politics. A supermajority insures that a razor thin majority can't end up doing something radically disagreeable to almost half the population. With a three to one supermajority you insure that only a true minority of the project would be in disagreement with whatever action is under consideration. Oh gee, so the US is using Condorcet now? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Supermajority requirements and historical context [Was, Re: First call for votes for the Lenny release GR]
On Sun, Dec 21, 2008 at 02:22:40PM +, Matthew Johnson wrote: On Sat Dec 20 17:51, Steve Langasek wrote: On Sat, Dec 20, 2008 at 12:48:43PM +0200, Antti-Juhani Kaijanaho wrote: In my eyes, this argument applies to any situation where a supermajority might be formally required, and in my opinion the corollary is that supermajorities are a bad idea in general. Do you agree with that corollary? If not, why not? Yes, I agree that supermajority requirements are a bad idea in general. Which is a perfectly reasonable attitude to have and I wouldn't be surprised if a vote to remove them from our constitution passed (I might even second or vote for it), but at the moment we _do_ have supermajority requirements and we can't just ignore them because we don't like them. Which is not what I have proposed. My only expectation is that supermajority requirements not be imposed for resolutions that *don't* explicitly modify the constitution or a foundation document (or override the TC). This argument does IMHO not apply to making decisions about what Debian is going to do. We shouldn't take decisions to set aside the DFSG lightly, but the *process* for arriving at a decision should be lightweight. By that standard, the past two months have been a failure on multiple levels. I think this all just goes to show that while _I_ don't think the constitution is ambiguous on this point and _you_ don't think it's ambiguous on this point, we both think it means different things, so it clearly _is_ ambiguous and this is a bad thing. I think we need to rewrite it to be clear and pick one position. I'm not even that bothered which one, but I will continue arguing for what I think our foundation documents mean (even if the vote goes against what I would prefer, if the majority says that). Perhaps you can propose some language that you think would unambiguously capture my position? I not only think the current language is unambiguous, I think the interpretation of supersede that has been tendered by the previous secretary is sufficiently unreasonable that I'm not sure what kind of change would be adequate to guard against such interpretations in the future; and I'd rather not have us bloat the constitution with any more language about this than absolutely necessary. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: General resolution: Clarify the status of the social contract
On Sat, Dec 20, 2008 at 08:23:27AM +, Matthew Johnson wrote: If this vote is 1:1 then there's no point in the 3:1 requirement since you can just ignore them with a 1:1 vote. When we (using the term loosely, since it doesn't include me) voted in the constitution, surely the 3:1 requirement was put there for a reason. When the constitution was ratified, it included no language at all about amending the foundation documents. See the links at the top of http://www.debian.org/devel/constitution for the relevant document history, and in particular http://www.debian.org/vote/2003/vote_0003 (and the extensive list discussion from the corresponding period) which established the concept of Foundation Documents and the terms under which they can be amended. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Supermajority requirements and historical context [Was, Re: First call for votes for the Lenny release GR]
On Sat, Dec 20, 2008 at 12:48:43PM +0200, Antti-Juhani Kaijanaho wrote: On Fri, Dec 19, 2008 at 04:36:59PM -0800, Steve Langasek wrote: if a majority of voters vote that we should put Nvidia drivers in main, then your fundamental problem is that you have a majority of people (or at least, voters) in Debian who think it's ok to put Nvidia drivers in main. Your only real choices, then, are to persuade them that they're wrong, live with it, drive them off, or leave. The other option you're proposing here, to prevent them from doing what they want to unless they have a 3:1 majority, reduces to coerce the majority to do what you say they should do, even though they don't think you're right. Do you really think that's a solution to the above pathological scenario? In my eyes, this argument applies to any situation where a supermajority might be formally required, and in my opinion the corollary is that supermajorities are a bad idea in general. Do you agree with that corollary? If not, why not? Yes, I agree that supermajority requirements are a bad idea in general. - They have unpleasant side-effects when coupled with Clone-proof SSD, by making certain types of strategic voting much more interesting to voters (i.e., strategizing about contributing to the quorum requirements for a particular option by voting it above or below FD when there's a mixture of supermajority requirements on a single ballot - precisely what I've seen discussed on Planet and IRC during the current voting round). http://lists.debian.org/debian-vote/2002/11/msg00343.html http://lists.debian.org/debian-vote/2002/11/msg00316.html - Their nominal purpose is to prevent a tyranny of the majority, but in practice they only place limits on the /size/ of the tyrannic majority; a commitment to consensus-driven decision making, plus the right of any DD to propose any compromise amendment they want to, are a much better approach to preventing tyranny of the majority, and where these methods are ineffective supermajority requirements won't help either, so supermajority requirements are entirely superfluous from that POV. http://lists.debian.org/debian-vote/2002/11/msg00241.html The only argument in favor of a supermajority requirement for foundation docs that I found compelling at the time this was brought up for discussion was the concept of institutional stability: if a particular change to the DFSG doesn't enjoy *strong* support from a majority, there's a significant risk of flip-flopping our Foundation Documents in a fairly short period of time, as opinions in the project shift, and it's better to let the Foundation Documents lag slightly behind opinion than to have a high degree of churn in our highest-profile statements of principle. http://lists.debian.org/debian-vote/2002/11/msg00357.html http://lists.debian.org/debian-vote/2002/11/msg00264.html http://lists.debian.org/debian-vote/2002/11/msg00253.html http://lists.debian.org/debian-vote/2002/11/msg00266.html This argument does IMHO not apply to making decisions about what Debian is going to do. We shouldn't take decisions to set aside the DFSG lightly, but the *process* for arriving at a decision should be lightweight. By that standard, the past two months have been a failure on multiple levels. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org P.S. A quote that I found amusing when going through old mail: I don't agree with your assumption that we're not clever enough to think of a way of introducing supermajority requirements without sacrificing an important property of CpSSD. http://lists.debian.org/debian-vote/2002/11/msg00311.html -- 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 Fri, Dec 19, 2008 at 02:12:01PM +, Matthew Johnson wrote: On Fri Dec 19 14:24, Raphael Hertzog wrote: It is. Does the resolution say what the new version of the foundation document will look like if it's accepted ? If yes, then it supersedes the document. Otherwise it doesn't. So, if someone proposes a GR saying we will ship the binary NVidia drivers in main and make them the default so that people can use compiz but doesn't say they are overriding the DFSG or provide the wdiff for it then that's fine and only needs 1:1 to pass? Yes, that's perfectly fine - and also non-binding, so the 80% of the DDs who didn't vote, the 47% of the voters who voted against it, and the 2% of the voters who didn't read before voting can ignore that position statement and continue doing things just as they were before. Just like, *constitutionally*, any individual developer can already ignore the Social Contract or DFSG at their discretion. This is not an argument that it's ok for developers to ignore the SC. I'm merely pointing out that adherence to the SC does *not* follow from the constitution, so *constitutional* arguments about why decisions to set aside the SC should require the same supermajority as superseding the SC are invalid! So please stop trying to use the constitution for an easy out when you want to override the conscience of your fellow developers. You still need a simple majority of people *in favor* of your GR in order to accomplish that; blocking an expression of the majority opinion by imposing a supermajority requirement that doesn't follow from the letter of the constitution does not accomplish that. The default is still that each developer is going to do what they personally believe is right. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: General resolution: Clarify the status of the social contract
On Fri, Dec 19, 2008 at 12:18:01PM -0800, Russ Allbery wrote: If we're going to have a vote on this topic, I feel quite strongly that every option which states the social contract is binding should include in it a constitutional amendment specifying *who* decides for the project what those documents mean and what the procedure is to override that decision (can't be overridden, requires a 3:1 majority to override, etc.). While formally I agree that this should be a requirement for such a system, I will vote against any such GR because all this does is add another layer of indirection to our decision-making process that we don't need. The heart of the dispute over the current ballot is that the secretary has assumed the power to intervene in the very process of how the project takes decisions. Regardless of whether this is acceptable under the constitution (which I don't believe it is), I think it's a very wrong model, and that if we're to make any changes at all they should be to *correct* this instead of codifying it. * Each individual developer when doing their own work (advantage: what we have now, according to my reading, but gives rise to lots of debate when those scopes overlap, such as when a GR is proposed and the secretary has to prepare the ballot) Given the privileged position of the secretary (immune even to direct recall by the developers), I think it should be made unequivocally clear that the secretary should not be interpreting the SC at all as part of the ballot drafting, and should be interpreting the constitution parsimoniously. But given that the constitution already calls for the secretary to engage in consensus-driven decision-making, I'm not sure how the latter can be made any more clear. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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 Fri, Dec 19, 2008 at 09:50:42PM +, Matthew Johnson wrote: Then the 3:1 requirement is nonsense and the SC and DFSG effectively optional. I don't believe that was the intention when they were drafted. They were drafted before the constitution was and their binding power does *not* flow *from* the constitution. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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 Fri, Dec 19, 2008 at 05:09:32PM +, Matthew Johnson wrote: Yes, that's perfectly fine - and also non-binding, so the 80% of the DDs who didn't vote, the 47% of the voters who voted against it, and the 2% of the voters who didn't read before voting can ignore that position statement and continue doing things just as they were before. So... you're saying there's no point at all in such a GR? The GR says we will do X but even after we pass it we still can't do X because it would contravene the SC or DFSG? How is that a useful thing at all? What's the point? The point in *allowing* this is to have a simple system by which the project's majority view can be expressed. On Fri, Dec 19, 2008 at 08:20:30PM +, Matthew Johnson wrote: But... _how_ can it be the case that having the NVidia drivers in main (sorry to keep on with this example, but I want something where it's clear whether it meets the DFSG or not) is what the project wants when it's clearly going against our foundation documents. There's an inherent contradition. The SC says we won't ship non-free stuff and the GR says actually we will ship non-free stuff (except we can't really because the SC says we can't). It makes no sense. In this hypothetical case which is not at all analogous to the complex issue currently under discussion: if a majority of voters vote that we should put Nvidia drivers in main, then your fundamental problem is that you have a majority of people (or at least, voters) in Debian who think it's ok to put Nvidia drivers in main. Your only real choices, then, are to persuade them that they're wrong, live with it, drive them off, or leave. The other option you're proposing here, to prevent them from doing what they want to unless they have a 3:1 majority, reduces to coerce the majority to do what you say they should do, even though they don't think you're right. Do you really think that's a solution to the above pathological scenario? NVidia drivers are just a placeholder to illustrate the point. You definitely _can't_ claim that they meet the DFSG (but you could change it to allow them anyway). However, you do raise something here which people may be confusing. A vote that said we will assume that firmware is in source form is very different to one which says we don't care whether or not it is source form. The former says we keep the DFSG as it is, but we are asserting that they comply unless we can prove otherwise and the latter says even if we can prove otherwise we will change the DFSG so that it is allowed The former is 1:1 and the latter is 3:1. It may be a subtle difference, but it's an important one, because it sets precedent for future issues where the difference is not so subtle. I think the difference between the two is that in the former we're blatantly lying to ourselves about whether we're in compliance and rewarding people for not providing evidence of non-compliance by giving them a timely release in return, and in the latter is being honest with ourselves and our users. I don't see why we should be encouraged to lie to ourselves. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: gr_lenny vs gr_socialcontract
On Fri, Dec 19, 2008 at 05:00:59PM +, Ian Lynagh wrote: We need some time to solve the problems that are in main the first time round I can live with, but uploading new instances of the same problems to main, I think this is a strawman that doesn't correspond either to what has actually happened in the archive, or to the declared intentions of the release team. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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, Dec 18, 2008 at 05:54:13AM -0600, Guilherme de S. Pastore wrote: It is in the basics of constitutional law. We cannot explicitly decide not to enforce the text of a foundation document, making an exception to its application, without reaching the quorum that would be necessary to excluding that text entirely and forever. Enforcement of the foundation documents is not defined in the constitution, so no, this is not a question of constitutional law. For a broader and easier to understand example, guess what would happen if Congress needed a 3:1 supermajority to amend a country's constitution, but only needed a 1:1 majority to say that actually, for the next couple of months, you don't need all this civil liberties crap, and we are suspending it. I'm not sure if you're being deliberately ironic here, or if you're just somehow unfamiliar with the past 7 years of US history? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
