Re: General Resolution: Declassification of debian-private list archives
I like the proposed GR by Anthony Towns. I don't think it is against our constitution, and I don't see how it can be breaking any trust, since the authors and other affected people can prevent publication. To make my support more concrete: I expect this GR gets passed, so I hereby declare my availability to become a member of the declassification team, should the DPL wish to delegate that task to me (and others). -- Talk is cheap. Whining is actually free. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: General Resolution: Declassification of debian-private list archives
to, 2005-12-01 kello 09:04 -0600, Manoj Srivastava kirjoitti: > On Thu, 01 Dec 2005 16:35:02 +0200, Lars Wirzenius <[EMAIL PROTECTED]> said: > > > I like the proposed GR by Anthony Towns. I don't think it is against > > our constitution, and I don't see how it can be breaking any trust, > > since the authors and other affected people can prevent publication. > > It is not at all clear to me that if my post was fully quoted > by another, then my wishes to have that quote redacted would be > honored. I may request it to be, and this shall be "taken into > consideration", but does that mean that the request should be > honored? I think it is obvious that it should be. It's your e-mail even when it's being quoted. -- Pity the sysadmin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR Proposal: GFDL statement
ke, 2006-01-25 kello 14:54 -0800, Jeff Carr kirjoitti: > By this argument, the GPL must be removed or authors must allow anyone > to modify it. Clearly the intent of the Debian community and the DFSG is > not to require abandonment of the protections of the GPL. This argument is old, wrong, and has been discussed already in this thread. License texts themselves are the exception, it's necessary for them to be allowed to be non-modifiable. Please don't repeat old arguments, this discussion is unmanageably big already. -- RFC 1437 - yet another MIME specification Microsoft ignores -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
ma, 2006-01-30 kello 09:24 +1100, Craig Sanders kirjoitti: > only indirectly. the real point, which you missed, was to be an accurate > description of reality - something that, as an extremist nutcase, you > are challenged by. > [ further insults deleted ] Craig, could you please behave in a polite manner? Regardless of whether you're right or wrong about your claims about the GFDL, your manner is inappropriate on Debian mailing lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
ma, 2006-01-30 kello 13:39 +1100, Craig Sanders kirjoitti: > i'll behave as i please. > > if you don't like my words, then don't read them - kill file me if you > feel it's necessary. Nobody has the right to be personally insulting on Debian lists. It would certainly be possible to express concern about the current issue without vitriol. Abusing other people hurts the discussion by poisoning the atmosphere and making it more difficult to be constructive and to reach a mutual understanding. Flaming and attacking people involved in the discussion is not going to help settle the issue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
to, 2006-02-09 kello 15:13 +0100, Xavier Roche kirjoitti: > On Thu, 9 Feb 2006, Henrique de Moraes Holschuh wrote: > > > Well, maybe the wording was not deceptive enough ? > > Maybe people should get re-acquinted with GR 2004-04 and its results before > > they bring up GR 2004-03, even for jokes. > > No, no. The funny joke is to modify the constitution with a deceptive > wording, with 214 votes out of 911 developpers. Please stop abusing that horse. We're running out of glue. -- Fundamental truth #2: Attitude is usually more important than skills. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Nomination
I hereby nominate myself as a candidate for the next Debian Project Leader. signature.asc Description: This is a digitally signed message part
De-nomination
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I hereby de-nominate myself as a candidate for DPL 2006. I have realized this week that there are aspects and parts of the project that I can't emotionally deal with. Especially abusive behavior on mailing lists, the vocal support for it, and the persistent resistance to any attempts to fix it. I thought I had grown a skin thick enough to deal with it, this past year, but I was wrong. I now find that I need to be able to ignore parts of the project or be unhappy. This makes me unsuitable to be the leader. A few people have encouraged me in public and in private to run for DPL, and I apologize for letting them down like this. In some ways, I am a loser. I'm publishing this half-finished draft of my DPL platform in the hopes that it can be useful in the upcoming debates, or gives food for thought otherwise. I'm skipping the part where I praise myself and recount my history in the project, since that is no longer relevant. Major goals === On the whole I think Debian is doing pretty well. We have some problems, and some of them are on the way of becoming big ones, but it's not too late to solve them. Major Goal: Make Debian discussion channels drastically less hostile - This is, I think, perhaps the biggest problem in Debian as of today. The big, high-volume Debian mailing lists, and to some extent their corresponding IRC channels, can be quite hostile. Many discussions become aggressive, and even seemingly innocent technical decisions turn out to be quite controversial, sometimes due to old grudges. This is bad for productivity, and bad for quality. It's also bad for getting new people to join, and for keeping old people. It's bad for keeping people happy to be part of the project. Many of our developers avoid debian-devel, debian-project, and debian-legal, for example, because they find it saps out the fun of working on Debian. Instead of feeling invigorated and re-motivated after a meeting of minds with friends, they feel angry, sad, and disappointed. This needs to be solved some way. A "code of conduct" has been suggested. We have a vague, really old one, that is pretty much never enforced. I think we should write a new one, and make sure the listmasters have the power to enforce it. Goal: Make all infrastructure jobs delegated or elected - --- The ftp-master team, the account managers, the system administrators, and the stable security team, at least, are not officially delegates of the DPL, or elected by the developers in general. I think this is bad for the project, in the long run. If the project in general thinks one of these teams works badly, it needs to be possible to replace or augment the teams, even against the wishes of the current teams. I don't care whether they are DPL delegates or whether we should change the constitution to have elections for them. I also suspect that we would benefit if more people worked on infrastructure teams, so that the knowledge needed to do the work is spread out more. Major goal: Better transparency for how the project works - - One of the lessons[*] Debian has learned is that it is necessary to keep things open and public. People need to be able to see what goes on in the project. For the most part, we do this very well: almost all our mailing lists are open for anyone to read, and they're archived, but there are some exceptions. [*] http://liw.iki.fi/liw/texts/debian-lessons.html The easiest example is the debian-private mailing list. There are some discussions that go on in there that really should be in public, even if they are not the nicest ones. Especially since they are not the nicest ones. Besides the demotivational factor of a private list, the privacy of the list is actually not very well protected, these days. Things leak, and they leak not only to, say, various N-Ms, but also to spouses and friends. I'm not so upset about the leaking, but of the uselessness of having supposedly secret discussions that don't actually need to be secret at all. Therefore I think debian-private should be abolished. We as a project do not have, and should not have, things we do or talk that can't be done in public. The vacation messages that go to -private are an exception. When we remove -private (or "if", I should say), creating a new, non-archived debian-vac list might be a good idea. I would also like to replace, as much as possible, the [EMAIL PROTECTED] address with a debian-project-leader pseudo-package in the bug tracking system. This would be an additional step in transparency. The DPL Team - The DPL team was a new idea last year. I think it was a good idea, but its execution has been lacking. Based on discussions I've had, it seems to me that it has suffered from the classic case of tea
Re: [OT] gpg signature (was: Re: De-nomination)
to, 2006-02-23 kello 19:59 -0300, Felipe Augusto van de Wiel (faw) kirjoitti: > Lars GPG signature failed to be checked. Obviously I am > missing something or did something wrong, but somebody can just > confirm that the signature is ok (or not)? Oh dear. Something, somewhere, mangled the message. Probably evolution. I've put an unmangled copy at http://liw.iki.fi/liw/temp/dpl-platform.txt.asc which should work OK. Thanks for point that out. -- Choose wisely, choose often. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Code of conduct, question to all candidates
Many people consider the aggressive, often unconstructive atmosphere on major Debian mailing lists to be a problem. You only need to make a little spark and suddenly you have ignited a huge thread, up to several hundred mails per day, a number of which are personal attacks. Even if they aren't, people insisting in mail after mail that their point of view is only correct one can be considered quite aggressive. And even if you disregard that, the mere volume of discussion is more than overwhelming, it can be outright scary. A code of conduct has often been mentioned as a possible solution to various communication problems we have. The code would have to specify, either explicitly or implicitly, some rules for acceptable behavior. What do you think of a code of conduct? What in your opinion would be a lower limit on acceptable behavior? Do you think that strict rules would be better than general guidelines? Who should be the judge if a particular case follows the code of conduct or not? Would the code be a good thing, or would it necessarily be a threat to freedom of speech, and stifle innovation? Should any kind of behavior be allowed on Debian mailing lists? -- The most difficult thing in programming is to be simple and straightforward. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reflections about the questions for the candidates
su, 2006-03-05 kello 03:11 +0100, Enrico Zini kirjoitti: > It would have been pointless to come out with such trivial reports. I disagree. They let the project know that things are going on (or not going on), and the DPL and Team are not just dormant, which was the impression I, at least, had for much of the past year. Compare to daily status mails from crontabs: if you don't get them, you can assume that something went wrong. And yes, a couple of times I did ask, although on IRC and not via e-mail. Having to drag out information gets tiresome so I only did it a couple of times. -- Happiness isn't happiness without a violin-playing goat. -- Notting Hill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reflections about the questions for the candidates
su, 2006-03-05 kello 14:20 +0100, Enrico Zini kirjoitti: > On Sun, Mar 05, 2006 at 10:44:17AM +0200, Lars Wirzenius wrote: > > > And yes, a couple of times I did ask, although on IRC and not via > > e-mail. Having to drag out information gets tiresome so I only did it a > > couple of times. > > Did you get answers when you asked on IRC? Not as far as I remember. -- Finland: where people go into 100 C rooms and eat ammonium chloride for fun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reflections about the questions for the candidates
su, 2006-03-05 kello 15:49 +0200, Lars Wirzenius kirjoitti: > su, 2006-03-05 kello 14:20 +0100, Enrico Zini kirjoitti: > > On Sun, Mar 05, 2006 at 10:44:17AM +0200, Lars Wirzenius wrote: > > > > > And yes, a couple of times I did ask, although on IRC and not via > > > e-mail. Having to drag out information gets tiresome so I only did it a > > > couple of times. > > > > Did you get answers when you asked on IRC? > > Not as far as I remember. To avoid misunderstandings: I asked (mostly, I think) from the DPL in private messages, and he may well have been away (even if not marked as such on IRC). I guess this is an example of a situation that would be avoided if as much DPL-related communication would be in public, say, via the BTS. -- If possible, use code, not comments. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question to all candidates about stable point releases
ke, 2006-03-08 kello 09:23 +0100, Marc Haber kirjoitti: > On Wed, Mar 08, 2006 at 05:46:53PM +1000, Anthony Towns wrote: > > On Wed, Mar 08, 2006 at 08:19:19AM +0100, Marc Haber wrote: > > > Feb 22nd, I mail both Joey (as SRM) and the security team noting the > > >queue changes that should happen "with a stable update > > >coming up" > > >From the information publicly available, I conclude that in the last > four weeks, the SRM has asked for the release to be made possible, > which has been answered with a request to implement queue changes > instead of making the release possible. I didn't understand it like that, that Anthony wanted Joey to implement the changes, but that Anthony offered to put the changes into effect now that there was a good chance to do it, rather than waiting for the next stable point release. Perhaps I misunderstood. -- I think, therefore I am alone in the universe. -- Over the Hedge -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Candidate questions: expulsions process
pe, 2006-03-10 kello 02:52 +, MJ Ray kirjoitti: > Matthew Garrett <[EMAIL PROTECTED]> > > Do you believe that anyone in Debian has ever been discriminated against > > for socio-religious views that had no impact on their ability to work in > > the project? > > Given the number of people in Debian, it seems probable that > one will have experienced religious discrimination unconnected > with their debian work at some point in their life. I don't > see how that's on-topic for -vote, though. A masterful evasion. The context was clearly discrimination in a Debian context. Please answer again. -- i++; /* TODO: make this pre-increment - more efficient */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: To all candidates: delegation process
su, 2006-03-12 kello 11:21 +1000, Anthony Towns kirjoitti: > if a delegation is necessary, make it, by posting the > details to -project, or if necessary, -private. Why -project and not -devel-announce? -- Policy is your friend. Trust the Policy. Love the Policy. Obey the Policy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Constitutional Amendment GR: Handling assets for the project
to, 2006-07-20 kello 20:12 -0500, Manoj Srivastava kirjoitti: > + 9.2. Authority > > +1. An organization holding assets for Debian has no authority > + regarding Debian's technical or nontechnical decisions, except > + that no decision by Debian with respect to any property held > + by the organization shall require it to act outside its legal > + authority. An exception is that Debian's constitution may > + occasionally use SPI as a decision body of last resort. I'm generally in favor of this amendment, but I think this paragraph may require clarification. In a quick reading it was unclear to me that the "it" in "require it to act" refers to the organization holding assets for Debian. Maybe substitute "the organization" for "it", even if it a bit longer. More importantly, the last sentence makes it sound that the Debian constitution requires the SPI to act illegally, whereas the exception really is to the fact that Debian doesn't have authority. I'm not sure how this is best fixed. (It's pretty clear what the text means. I'm trying to forestall future bad re-interpretations to make it mean something else, like the attempt to make only the SPI be able to hold assets for Debian that we've seen in recent times, which makes use of an ambiguity in the wording of the constitution.) -- RFC 1437 - yet another MIME specification Microsoft ignores -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
ke, 2006-08-23 kello 10:30 +0200, Bas Zoetekouw kirjoitti: > > 3. supports the decision of the Release Team to require works such > > as > > images, video, and fonts to be licensed in compliance with the DFSG without > > requiring source code for these works under DFSG #2; and > > > > 4. determines that for the purposes of DFSG #2, device firmware > > shall also not be considered a program. > > Would it be possible to vote on these two issues seperately? I would like that too. -- Debian is a beast that speaks with many voices -- Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes for "GR: Recall the project leader"
On la, 2006-10-07 at 18:55 -0500, Debian Project Secretary wrote: > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > 49a98df6-2bd4-40c8-a559-7e15212dbd26 > [ 2 ] Choice 1: Recall the project leader > [ 1 ] Choice 2: Further discussion > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- signature.asc Description: This is a digitally signed message part
Re: Question for Gustavo and Sam: bringing back the fun
On to, 2007-03-15 at 16:05 +0100, Pierre Habouzit wrote: > On Thu, Mar 15, 2007 at 11:15:03AM -0300, Margarita Manterola wrote: > > 1) flamewars: the constant bickering on mailing list is depressing, it > > takes away a lot of time, and it gives the whole project a bad > > reputation. > > FWIW you're not _forced_ either to read them, nor to participate. I've tried not participating or reading lists with large flame contents: for significant parts of 2006 I did not read -devel and -project (for instance). The result was that you're cut off from any sense of what the project is doing and where it is going. You tinker with your own packages, but you're not really part of the development community. The only reason I didn't completely drop out was because I stayed on #debian-devel on IRC. -- Debian is a beast that speaks with many voices -- Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for Gustavo and Sam: bringing back the fun
On to, 2007-03-15 at 16:52 +0100, Julien BLACHE wrote: > The only thing that changed is that some people started bickering > about the flamewars. Ah yes, I remember that happening. In about 1995. -- sic transit discus mundi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Constitutional amendment: reduce the length of DPL election process
On ti, 2007-07-31 at 09:49 -0700, Russ Allbery wrote: > I will definitely second such a proposal, unless former DPLs come > forward > to say that this just wouldn't work for some reason. I'd like to hear that, too. Speaking as someone who once almost was a candidate, I would like to point out that a two-year commitment is rather more difficult to make for many people than a one-year commitment. That is not a reason to avoid doing it, but it should be considered. -- Wolfen one, you are my midday moon and I your midnight sun. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Constitutional amendment: reduce the length of DPL election process
On ti, 2007-07-31 at 23:04 +0200, Julien BLACHE wrote: > Lars Wirzenius <[EMAIL PROTECTED]> wrote: > > > Speaking as someone who once almost was a candidate, I would like to > > point out that a two-year commitment is rather more difficult to make > > for many people than a one-year commitment. That is not a reason to > > avoid doing it, but it should be considered. > > Note that you're still free to step down after one year, so that's > hardly a problem (of course it's better if you announce your intention > to serve only for one year during the campaign...). "I know the job is for two years, but I only want to do half the job, so please vote for me, I'm better than those others who are willing to do the whole job." I would not vote for such a candidate; I would not be such a candidate. Your mileage may vary, of course: I am not suggesting my sense of doing the right thing is the right one for everyone. -- You need fewer comments, if you choose your names carefully. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Constitutional amendment: reduce the length of DPL election process
On su, 2007-08-05 at 01:07 +1000, Anthony Towns wrote: > On Sat, Aug 04, 2007 at 11:54:15AM +0200, Pierre Habouzit wrote: > > GRs do not unite, they divide. They divide the DDs in two: the one > > the losers and the winners. > > Just because your argument doesn't win the day doesn't mean you're a > loser, or divided off from the rest of the project. FULL AGREEMENT STOP GRACEFULLY ACCEPTING LOSS VITAL STOP COME TO BLANDINGS NEXT WEEKEND STOP ANATOLE IN TOP FORM STOP -- Debian is a beast that speaks with many voices -- Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to: reduce the length of DPL election process
On ke, 2007-08-08 at 18:47 -0700, Don Armstrong wrote: > The main issue from where I sit is allowing enough time for nominees > to post position statements and to have enough time for those position > statements digested by the electorate, and enough initial discussion > to occur so that interesting questions can be found for the debate. If > candidates don't have these ready at the beginning of the campaign > period, then the quality of the debate (and discussion) suffers. I, as a voter, would also like to have ample time for discussion about various topics after the IRC debate. Given the spread we have to many time zones, and the speed with which discussions progress (not to be confused with the number of e-mails per second), a week for discussion really does sound to me like too little time. Hurried campaigning does not seasoned choices make. -- Debian is a beast that speaks with many voices -- Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to: reduce the length of DPL election process
On to, 2007-08-09 at 10:25 +0100, MJ Ray wrote: > Lars Wirzenius <[EMAIL PROTECTED]> wrote: > > I, as a voter, would also like to have ample time for discussion > about > > various topics after the IRC debate. [...] a week for discussion > > really does sound to me like too little time. > > Note that there could still be up to three weeks for discussion after > the IRC debate but before voting closes. Or possibly only two weeks, if aj's proposal to shorten it goes through, as well. And that's still assuming our IRC debate happens right at the beginning of the one week campaining period, when people still haven't come up with good questions to candidates, or issues and themes to discuss. To me, that is a bad way of dealing with an important discussion. Our voting period is long to deal with the fact that we are an international organization of people with wildly varying demands on our time. Otherwise, we could make the voting period be only one day, but that would exclude people on vacation, work trips, ill, or otherwise unable to attend to Debian things during that day. That would exclude too many people, or require us to set up an absentee ballot system, and a long voting period is so much simpler. I think shortening the voting period to two weeks won't exclude very many people. If it does, we should hopefully hear about them soon, before we vote on aj's amendment, in which case I expect we'll be able to vote for the shortening of the nomination period separately. Replacing part of the campaining period with the voting period is again bad for people who can't follow Debian full time. aj's proposal shortens the time people have to discuss things with candidates from six weeks to five; you would shorten it to three. To me, that is too short. I am also uncomfortable with the assumption that the vigorous discussion we often have during the campainig period would continue throughout the voting period. While I don't endorse a full ban on discussion during the voting period, unless we shorten the voting period to one or two days, courtesy if nothing else has kept the voting period mostly free of discussion during the past elections. If the voluminous discussion continues through the voting period, that effectively does reduce the useful voting period to just a day or two. Otherwise you can't vote early without missing the discussion, and voting while ignoring most of the discussion is a bad idea, I think. -- Communication via acronyms is rfs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On ma, 2008-03-10 at 13:48 +1100, Anthony Towns wrote: > The idea is to encourage DPLs to appoint two new members during their > term, so we get new blood in the committee, Would it then be better to limit the term of tech-ctte members to, say, two years? Or three years? With the option that they may be re-appointed/elected/selected/whatever immediately, of course. This would force the consideration of new blood rather than making it dependent on the whim of the DPL. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations in Lenny: new proposal
I second Manoj's proposal below. ma, 2008-11-10 kello 12:21 -0600, Manoj Srivastava kirjoitti: > ,[ Proposal 5: allow Lenny to release with firmware blobs ] > | 1. We affirm that our Priorities are our users and the free software > | community (Social Contract #4); > | > | 2. We acknowledge that there is a lot of progress in the kernel firmware > | issue; most of the issues that were outstanding at the time of the > | last stable release have been sorted out. However, new issues in the > | kernel sources have cropped up fairly recently, and these new issues > | have not yet been addressed; > | > | 3. We assure the community that there will be no regressions in the > | progress made for freedom in the kernel distributed by Debian > | relative to the Etch release in Lenny (to the best of our knowledge > | as of 1 November 2008); > > | 4. We give priority to the timely release of Lenny over sorting every > | bit out; for this reason, we will treat removal of sourceless > | firmware as a best-effort process, and deliver firmware as part of > | Debian Lenny as long as we are legally allowed to do so, and the > | firmware is distributed upstream under a license that complies > | with the DFSG. > ` > > This is just proposal 2 + the last clause of item 4. I am > formally proposing this as an amendment, either to replace proposal 2; > or as a formal alternative in its own right, and I am asking for > seconds. signature.asc Description: Digitaalisesti allekirjoitettu viestin osa
Re: Discussion period: GR: DFSG violations in Lenny
ti, 2008-11-11 kello 16:39 +0100, Adeodato Simó kirjoitti: > Have you thought for a second, though, that the project as a whole could not > agree with you in not sharing that view? It is to determine the will of the project as a whole that we have the GR process. Until then, it's all speculation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
ke, 2008-11-12 kello 15:41 +, Steve McIntyre kirjoitti: > I think I agree with the suggestion of creating a new archive section > for firmware - packages that are acknowledged to not meet the same > standards as main, but checked so that we know they're still legally > shippable by default on official installation media. That's what Ubuntu does, for what it's worth. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
(Quote attribution elided on purpose.) > Stop your FUD. > > The Release Team isn't violating the Social Contract. It is my opinion that releasing lenny with known DFSG violations is a violation of the Social Contract, on the part of the project as a whole, regardless of which individuals are making the decisions. I further think that including sourceless firmware in main is a DFSG violation. It is my firm belief that the decision to violate the SC with a release should be taken by the project as a whole, via a GR, and that individual members, whether delegated or not, cannot make that decision. Based on recent discussions it seems to me that the release team is attempting to release lenny speedily and taking on itself to decide that the SC violation is acceptable. Thus, I think Robert is correct: the release team is violating the Social Contract. Further, I find it unacceptable to attack him for attempting to discuss this (mostly in a constructive manner, no less) and attempting to have the project decide on this via a GR. I would find it unacceptable even if it turned out that Robert was wrong. We should refute his arguments by counter-arguments based on fact, not by harrassing him. So far, most people disagreeing with Robert seem to be counter-arguing him, not his arguments. I understand that the people most involved in release management find it very frustrating that the freeze is taking a long time, but taking that frustration out on Robert is not the way to solve this. I also understand that the firmware issue is quite controversial in Debian. That's a reason to think carefully, not to blast out personal attacks. Or, indeed, to blast out lots of e-mails on this topic at all. On the whole, this discussion has had little sanity, and even less thoughtfulness, courtesy, and civility. Shame on us. For the record, I'm all for releasing lenny with the current known sourceless firmware included, like we did for sarge and etch. Every release gets better than the previous in this regard, so there's progress. However, I do not see that the previous votes are justification for automatically taking the same decision for lenny, without voting. I might even vote for a decision to have a permanent release exception, although I wouldn't vote for including sourceless firmware in main. I admit that given how little I've helped with lenny during its entire development cycle I have little ground to stand on, but I am not going to let that get in my way to the soap box. Thank you for listening. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
ke, 2008-11-19 kello 07:58 +0900, Charles Plessy kirjoitti: > Manoj, > > I completerly agree. > > How about allowing the Project to release Lenny without changing the DFSG? That is what Manoj proposed on 2008-11-10 in http://lists.debian.org/debian-vote/2008/11/msg00060.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bundled votes and the secretary
to, 2008-12-11 kello 08:50 +0100, Raphael Hertzog kirjoitti: > Manoj, I still object to voting all at once and I'm convinced that you > will manage to hurt the project by doing that. I, on the other hand, think Manoj has explained well why he is doing things the way he is doing with this vote, and I agree with his reasons. -- 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.
ma, 2009-03-09 kello 19:37 +1100, Ben Finney kirjoitti: > Matthew Johnson writes: > > > How about accepting that "he" is the gender-neutral pronoun in > > English? > > Because that's not true; “he” is a male-gender pronoun. While I agree with Ben, perhaps we could retire this, the 12765th iteration of this discussion, in favor of having a discussion about platforms and some Q&A with the candidates? -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
All candidates: Membership procedures
la, 2009-03-21 kello 01:42 +, Steve McIntyre kirjoitti: > P.S. Damn, just read Zack's answer and we don't seem to differ very > much. Oh well... :-) Dear Zack McIntyre, Steve Claes, and Luk Zacchiroli, What's your opinion on membership procedures? Last year there were some rough proposals for how to change the membership procedures. It started with Joerg's proposal, but other people suggested their own kinds of changes, including me. I feel that my approach and Joerg's are pretty much diametrically opposed. What's your opinion? Do you feel the current NM process works well and almost always selects for the kind of people that are really great for Debian? Would some other kind of process work better? What kind of membership process would you like to see in Debian in, say, a year from now? Please feel free to dream, there's no point in being too constricted by reality and practical considerations. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: All candidates: Membership procedures
su, 2009-03-22 kello 17:01 +0100, Luk Claes kirjoitti: > I think we first have to think about what a member, if we need different > types of access/members and what they would be before thinking about the > process(es) to become a member. I do think for instance that > contributers who spend a lot of effort in Debian (like for instance some > translators) should be able to become a member and so be able to vote. Translators can already become members of the project, as far as I know. For the rest of your answer, I must admit I remain in the unclear about what you think, Luk: the questions you raise are certainly questions that should be raised in this discussion, but do you have answers or opinions on them, even if preliminary? I'm not looking anything set in stone, but I'd like to know what the candidates think on these issues. Do you think the current process if mostly fine, or you think it needs to be scrapped and re-created from scratch? Or something else? I'd also be fine with an answer just saying that it's not an issue the candidate has spent much time thinking about, and so does not have an opinion on it at the current time. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: All candidates: Membership procedures
ma, 2009-03-23 kello 14:52 +0100, Stefano Zacchiroli kirjoitti: > I'm going to respond to this as soon as I complete my backlog of > week-end email. In the meantime I've a request that will help people > following this discussion. Can you please point us all to your > proposal, possibly revised with changes raised in the discussion, if > any? I do remind your proposal, but I'm not sure whether it was > significantly changed during the subsequent discussion or not. My message is here: http://lists.debian.org/debian-project/2008/10/msg00145.html However, I'm asking the candidates to hear what their opinions are on how Debian should handle membership. I don't desire a detailed commentary on the various proposals (if only since that would take a lot of time to write and read). I am interested in the candidates' opinions, rather than their reactions to other people's opinions. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GR: welcome non-packaging contributors as Debian project members
On ti, 2010-09-14 at 17:53 +0900, Stefano Zacchiroli wrote: > The Debian project therefore invites the Debian Account Managers to: > > * Endorse the idea that contributors of non-packaging work might become > Debian Developers without upload rights to the Debian archive. These > new developers shall be recognized as Debian Contributors (DC). I support Zack's proposal, but with a caveat. I do not like the introduction of yet another class of person developing Debian. I propose we call everyone with voting rights in Debian a "Debian Developer" (development not being restricted to coding and packaging). Voting, not uploads, being the fundamental right of a member of the project, and the most important reward we can give for someone who works for Debian. I also feel we don't need to implement a technical barrier against uploading. I don't think technical skills are the relevant thing when it comes to deciding whether someone should be allowed to upload or not. The important thing is whether we trust them or not. If we don't trust them, they shouldn't be any kind of member in the project. If we do, we should trust them to not intentionally make a mess. Mistakes are not that important: everyone makes mistakes, and we need to be able to recover from them anyway. But this is perhaps a bit radical of an opinion in Debian right now. (I was under the impression there was a hypothetical path to becoming a DD for people who do not want to do packaging work. I am sure I heard someone say they had gone through that path years ago, but perhaps I remember wrongly.) -- 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/1284461384.2573.26.ca...@havelock
Re: GR: welcome non-packaging contributors as Debian project members
On ti, 2010-09-14 at 13:14 +0200, Christoph Berg wrote: > Re: Lars Wirzenius 2010-09-14 <1284461384.2573.26.ca...@havelock> > > I do not like the introduction of yet another class of person developing > > Debian. I propose we call everyone with voting rights in Debian a > > "Debian Developer" (development not being restricted to coding and > > packaging). > > We are calling everyone "Debian Developer" (cf. the constitution). DCs > are a subset of DDs. We realize that we probably need a handy > expression for "DD with upload rights" [1], but we don't have one yet. > (Ideas?) Could we please instead not invent new names and call ourselves "DD with upload rights" and "DD without upload rights"? We already have a problem with terminology for various kinds of memberships. Let's not make it worse. > I do agree with the idea, but it opens up gray areas. There will be > DCs who maintain some (maybe documentation-only?) packages, and will > become DM for these. With the no-difference idea, it is unclear where > the line to "classic DD" is. And voila, you end up being a fully > uploading DD who has skipped T&S in the NM process. > > It's probably possible to do, but it has to be well-thought. Making > T&S a formal (and technical) prerequisite to the "uploading" part cuts > a clear line. I re-iterate that I think the important distinction is one of trust. Not skills. -- 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/1284464484.2573.39.ca...@havelock
Re: GR: welcome non-packaging contributors as Debian project members
On ti, 2010-09-14 at 18:56 +0200, Lucas Nussbaum wrote: > My own preference is [B] > [A] > [original GR proposal]. But I'd like to > hear some other opinions before working on a draft amendment for either > [A] or [B]. I'd prefer [A] == [B] > [original GR proposal] > [NOTA]. -- 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/1284492567.2573.52.ca...@havelock
Re: Naming of non-uploading DDs (Was: GR: welcome non-packaging contributors as Debian project members)
On ke, 2010-09-15 at 09:26 +0200, Lucas Nussbaum wrote: > If we go for DDs without upload rights, I think that we should be > extremely careful about not transforming this new kind of DDs into > second-class > members of the project. A way to do that is to avoid giving them a name, > and emphasize the fact that they are DDs, not another sub-kind of > project members. The "no upload rights" part would just be a minor > technical distinction. > > Another way to put it is, imagine you are a DC, and are writing your CV. > What should you write about your status in Debian? "Debian Contributor"? > "Debian Developer"? If we create the "Debian Contributor" term, then I'm > sure that for many DCs, it will be difficult to write "Debian Developer" > there (Imposter Syndrome, etc), even if that's what should really be > written, since their contributions to Debian are not less important than > those of other DDs. > > Just leaving it up to DAM to choose a term would not be enough to avoid > that. IMHO, DDs without upload rights should not have any sexy name, and > the distinction between them and DDs with upload rights should only be > made where it's necessary. > > I don't think that the IRC conversation example you gave is a convincing > one. It wouldn't hurt much to write "I'm a DD without upload rights" > instead of "I'm a Debian Contributor" (it's only 6 characters more!). I fully agree with Lucas. -- 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/1284536165.2573.54.ca...@havelock
Re: Naming of non-uploading DDs (Was: GR: welcome non-packaging contributors as Debian project members)
On su, 2010-09-19 at 11:33 +0200, Stefano Zacchiroli wrote: > On Sat, Sep 18, 2010 at 09:36:50AM -0500, Kumar Appaiah wrote: > > > Even better, now with attachments! > > There is yet another pronoun I have missed. Please find a patch > > attached. > > Applied (wording / punctuation fix), thanks! > > New current text is attached. Seconded (sha1sum of attachment was 3dc10c8dcee25fd9af5d8895ad4bd2d9176b9397). signature.asc Description: This is a digitally signed message part
Re: Nomination [Re: Debian Project Leader Elections 2011: Call for nominations]
On la, 2011-03-05 at 08:58 +0100, Sean Finney wrote: > I nominate Stefano Zacchiroli. > > I of course understand if he wants to take a break after the last year, > but couldn't pass up the chance to be the first to make the > (re-)nomination :) I think Zack's done an awesome job as DPL. However, we only accept self-nominations for DPL. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- 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/1299312505.2986.24.ca...@havelock.lan
Question for Stefano: New contributors
The GR to be welcoming to non-packaging contributors was a good thing. However, it addresses the end of the membership process, the actual membership. Before they even enter the NM process, we need to get them contributing to Debian. What is your assessment of the situation at that end, Stefano? Are we frequently getting non-packaging people contributing to Debian, and becoming a part of the development community, or are such people rare exceptions? What, in your opinion, could we do to attract more of them? What barriers are there that we could lower? Are there particular kinds of skills we need? What about packagers? How could we attract more of them, and get them to stay in the project? -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- 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/1300351785.2771.91.ca...@havelock.lan
Re: Question for Stefano: Length of the DPL term
On la, 2011-03-19 at 15:20 +0100, Stefano Zacchiroli wrote: > Something that might work is that at midterm the DPL has to explicitly > state whether they are willing to continue for another midterm or > not. Alternatively, we could apply to the DPL what I've suggested applying to all DDs: if you're inactive for too long, then you're automatically retired. For the DPL, if we haven't heard from them in, say, two months, then the secretary could investigate and figure out what's going on, and decide whether to start a new election process or not. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- 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/1300609293.2879.4.ca...@havelock.lan
Re: Question for Stefano: Length of the DPL term
On la, 2011-03-26 at 18:30 +0100, Stefano Zacchiroli wrote:
> On Sun, Mar 20, 2011 at 08:21:33AM +0000, Lars Wirzenius wrote:
> > For the DPL, if we haven't heard from them in, say, two months, then
> > the secretary could investigate and figure out what's going on, and
> > decide whether to start a new election process or not.
>
> Leaving the decision to the secretary alone is not something I would
> like to see in any sort of constitution. (Not that I don't trust the
> secretary or anything, but a constitution is exactly the place where you
> generally want to be exceedingly paranoid.)
I agree that the constitution should be paranoid. That's why I would not
let the secretary decide to start an election all by themselves.
Instead, there would be an objective trigger ("no gpg-signed e-mail from
the leader on any Debian mailing list in the past 60 days"), with the
role of the secretary being to act as a safeguard that postpones the
start of the election if there's a reason to do so.
This would be similar to the current situation, where we have an
objective trigger ("1 year since the current DPL's term started") for
the secretary to start an election.
In both cases, if the secretary is failing, then the develpers at large
can step up and raise the issue.
--
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/
--
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/1301250114.11500.6.ca...@havelock.liw.fi
Re: Comments on the constitution?
On Mon, Aug 29, 2011 at 12:33:15PM -0400, Joey Hess wrote: > ... Would perhaps be to have people state that they are only interested > in a pro-forma election. If there's a consensus that the current DPL is > well respected and should continue, then we could skip strawman > candidates, DPL platforms, Q&A sessions, etc. (If NOTA wins, the > consensus was false and we have to try again.) I'd prefer to see 1-year DPL terms and quite a short election process: 1 week for nominations, 1 week for platforms + discussion, 1 week for voting. That should take the pain out of re-election, even as the only candidate, and avoids having to require candidates to commit to two years of DPLship, which can be hard to do, when it requires buy-in from spouses, family, and employers (since the DPL will usually travel a lot). -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ -- 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/20110829210925.ga21...@havelock.liw.fi
All candidates: Development and technical issues and challenges
Gegerly, Moray, and Lucas: We're currently in the middle of a freeze for the next release. We've been in this release since June 30. That's over eight months. That's a long time, even for a project the size of Debian. Releasing when we're ready is all well and good, but it's a problem when it takes us so long to get ready. In your opinion, what are the fundamental reasons the release freeze is so long, and so painful, and what do you propose to do, as DPL, to fix them? What other development process problems do you see, ones that do not directly affect the freeze, but make the development of Debian less productive or less interesting? Finally, what are the main technical challenges you see for Debian in the next five years and what should we, as a project, do about them? -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers signature.asc Description: Digital signature
Re: GR proposal: code of conduct
On Thu, Feb 27, 2014 at 11:42:47PM +1100, Stuart Prescott wrote: > Conduct is about behaviour and social interaction. A CoC is about the > emotional contents and effects of the message not about how it was delivered > or how many bytes there were between newline characters. > > To me the strength of the CoC draft we are looking at here is that it > doesn't concern itself with trivialities or with specific media. It talks > about conduct -- that is behaviour, deportment, how we want people interact > as human beings -- be respectful, be collaborative, assume good faith, be > concise, be open. These are all about social interactions and not technical > details on character limits, attachment sizes or whether people get CCs on > messages. None of these technical things are conduct, they are, if you like, > protocol. The CoC could happily refer to medium-specific guidelines for such > minutiae if they are necessary. > > Let's not spend the next decade working to flesh out a 200pp document full > of subsections for each different communications protocol we might use. Such > a document becomes useless to everyone. > > Let's not overcomplicate this with rules-lawyering. I am astounded by the slenderness of the delta between what Stuart says above and the thoughts in my head I have been trying to extract and express without success. In other words, "me too", "+1", and "hear hear". -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140227134526.ga16...@mavolio.codethink.co.uk
Re: GR proposal: code of conduct
I second Wouter's proposal and both of Neil's amendments below. (I haven't counted the current seconds for the amendments. The -vote page indicates there's not enough.) On Wed, Mar 05, 2014 at 06:05:45PM +, Neil McGovern wrote: > On Wed, Mar 05, 2014 at 05:53:48PM +, Neil McGovern wrote: > > Seconded, but I'd also like a couple of amendments which I'll add in > > another mail. > > > > And here's those amendments. > > Amendment A - move mailing list CoC text to "further reading" > Justification: I think that it's better to keep the CoC as a general > purpose document, rather than have it specific to each medium. The > information at http://www.debian.org/MailingLists/#codeofconduct is > still useful as it stands. > > I'm hopeful Wouter will accept this one, as I don't think it > substantially changes the CoC. > > - > participants to its mailinglists, IRC channels, and other modes of > communication within the project. > > -2. The initial text of this code of conduct replaces the "mailinglist > - code of conduct" at http://www.debian.org/MailingLists/#codeofconduct > - > -3. Updates to this code of conduct should be made by the DPL or the > +2. Updates to this code of conduct should be made by the DPL or the > DPL's delegates after consultation with the project, or by the Debian > Developers as a whole through the general resolution procedure. > > -4. The initial text of the code of conduct follows, in markdown format. > +3. The initial text of the code of conduct follows, in markdown format. > > # Debian Code of Conduct > > [snip] > - Debian has a [diversity statement](http://www.debian.org/intro/diversity) > - The [Debian Community Guidelines](http://people.debian.org/~enrico/dcg/) >by Enrico Zini contain some advice on how to communicate effectively. > +- The [Mailing list code of > + conduct](http://www.debian.org/MailingLists/#codeofconduct) is useful for > + advice specific to Debian mailing lists > - > > > Amendment B - Updates to the CoC should be via developers as a whole > Justification - I believe that this document should have the strength of > being a whole project statement. Being able to be updated by a single > person doesn't feel comfortable with me. > > I'm less convinced Wouter will accept this, but I think it should be on > the ballot! > > - > 2. The initial text of this code of conduct replaces the "mailinglist > code of conduct" at http://www.debian.org/MailingLists/#codeofconduct > > -3. Updates to this code of conduct should be made by the DPL or the > - DPL's delegates after consultation with the project, or by the Debian > - Developers as a whole through the general resolution procedure. > - > -4. The initial text of the code of conduct follows, in markdown format. > +3. The initial text of the code of conduct follows, in markdown format. > > # Debian Code of Conduct > - > > Thanks! > Neil > -- -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers signature.asc Description: Digital signature
All DPL candidates: level of team management
For all DPL candidates: We have a number of delegated teams. How detailed should the delegations be? What is the appropriate level of oversight, management, and control that the DPL and the project in general should have for deciding what the teams work on, and how they do their job? -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140311204941.GP23248@holywood
Both DPL candidates: handling social conflict
On Tue, Mar 11, 2014 at 08:49:41PM +, Lars Wirzenius wrote: > We have a number of delegated teams. How detailed should the > delegations be? What is the appropriate level of oversight, > management, and control that the DPL and the project in general should > have for deciding what the teams work on, and how they do their job? Thank you, Lucas and Neil, for your answers. My interpretation of them is that you're both roughly on the same lines, with differences mainly in style and approach rather than substance. I don't have follow-up questions on those, and I'm happy with your answers. Since nobody else is asking questions, I'll ask another one, which again I am unable to distill into a single sentence. We have, from time to time, situations within the project where people's feelings are strong and raw at the same time. These might turn into outright flame wars, but even before they go that far, they can be damaging. For example, most of the init system discussions of the past couple of years haven't been flame wars, but they have been divisive and have caused hurt feelings and generally made Debian be less fun for a lot of people. Some of these situations are traditionally difficult for us to deal with. Clear trolling, or name calling, or unambiguous flaming is easy to deal with. Where we typically fail, as a project, is dealing well with situations when people mainly talk past each other, not listening to the other parties, and are entrenched and uncompromising, leading to quite voluminous discussions that often don't make any progress. My question is: what do you think we, as a project, and you, if elected as DPL, can do to handle such situations, and ideally prevent them? I am asking a general question, not specifically about the init discussions. In previous years we've had a number of discussions about this, and in those a "social committee" has been proposed. What do you think about that? -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140313090527.GT23248@holywood
Both DPL candidates: appropriate choice of dresswear for the DPL
On Fri, Mar 21, 2014 at 01:44:54PM +0100, Wouter Verhelst wrote: > However, Debian is not a cult. Indeed not. We are a clan. Which inspires my next question. Neil and Lucas: do you have, or will you get, a Debian kilt and wear that for Deconf14? -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers PS. Yes, this is a joke question. No need to actually answer. I am just trying to be quoted in LWN. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140321132010.gf4...@mavolio.codethink.co.uk
Re: All DPL candidates: Debian assets
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? -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140321160257.gg4...@mavolio.codethink.co.uk
Re: ``Disclaimer'' field to document non-free-ness reasons [ Was: non-free? ]
On Thu, Mar 27, 2014 at 10:23:05AM -0700, Russ Allbery wrote: > Stefano Zacchiroli writes: > > Questions for my -policy friends: can I conclude from the above that the > > Disclaimer field is to be used _only_ for contrib/non-free packages, and > > only to explain the reason of their (transitive) non-free-ness? Or is > > there a risk of overloading it for other reasons? (The current text > > implies it is not, but the name is a bit generic, and I prefer safe over > > sorry.) > > I believe the intent was for it to be used only for this purpose. It > probably would have been better to give it a more unambiguous name. As one of the DEP5 drivers, I believe Russ is correct. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140327173202.gd5...@mavolio.codethink.co.uk
Re: All DPL candidates: DPL Term lengths and limits?
On Fri, Mar 28, 2014 at 01:24:13PM +, Steve McIntyre wrote: > On Fri, Mar 28, 2014 at 10:06:00AM +0100, Lucas Nussbaum wrote: > >The 2-week voting period made sense when the Constitution was written, > >as intermittent internet access was much more likely back then. But > >today, it's probably less justified. > > Do you want to disenfranchise DDs who are on vacation? Even if we keep the two-week voting period, there'll be people who can't vote because they're away exactly those two weeks, even if it's fewer of them. Knowing the voting dates beforehand would help with planning. That said, I am in favour of keeping the existing voting period. All the energetic parts of the DPL election process mostly cease by the time the discussion period ends, so a longer voting period doesn't cause us to spend more effort on the DPL election. The only benefit from shortening the voting period would be to reduce load on www.debian.org from people who keep refreshing the results page to see if the results are known yet. Personally, I don't see the need to shorten the DPL election process at all. It's _good_ to stop and review where we are, and what we're about. Spending three weeks on that each year is not too much. I understand that it's much more effort to the DPL candidates themselves, but if you can't handle that, then you probably shouldn't run for DPL. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140328135650.ge5...@mavolio.codethink.co.uk
Re: Re: Re-Proposal - preserve freedom of choice of init systems
Hi, Svante, I fear your wonderfully terse phrasing may cause some people to react more negatively to what you said than you perhaps intended. Please forgive me for the boldness of suggsting alternate phrasings below, in the hope of clarifying things for everyone. Svante Signell: > It is well known that the users are second class citizens with respect > to Debian. I suggest, instead: It is well known that in Debian, most of the time, those who do the work get to make the decisions. Since almost all work in Debian is done by volunteers in their free time, it would indeed be strange to require that other people could dictate what they do. It would not be fun for long to be a Debian contributor, if any random person on the Internet could order them to do something, at the random person's whim, on pain of insults and harrassment. Users are very important to Debian developers, and it even says so in the social contract the Debian project has published. Its users can have a big impact on how Debian gets developed in the future, when they join development discussions to explain their use cases, needs, and individual situations, and engage the project in a constructive way. Despite this, Debian quite sensibly sticks to the principle of "those who do, decide" and only counts votes for those who've contributed enough to become formal members of the project. That's a bit longer, and not nearly as pithy, but I hope it conveys your intention better. > The same applies to many upstream developers, they develop software > mainly for themselves, not the users, see for example the latest > development of Gnome. The only way to change this is by creating a large > enough user group taking side by refusing to use software that is going > in the wrong direction and promote alternatives. I would phrase this like this, instead: The same thing applies to everyone who works on free software in their free time: they'll work on what they want to work on, and if that is to a random person's liking and benefit, that's a very lucky random person. Most developers do listen to their users, and even random passers-by with an opinion, but they don't let them decide things. However, the developers get a big ego boost from making something that people like. A similar thing applies to those who get paid to work on free software: they work on things their employer wants them to work on, and perhaps make decisions that benefit their employer more than a random person. This tends to mean they keep getting paid. One can imagine a hypothetical situation where random people show up and demand and insist that they get to decide on what developers work on, what they do, how they do it, etc. These people might even be long-time users of the software, who feel they such a long history with the software, they're entitled to some decision making power. To make the situation even more ridiculous, the random people could use really inflammatory language, such as substituting "wrong" for "I don't like". This situation would be really stressful and depressing for the developers, and one would wonder why they would put up with it. It would be much easier for them to just quit and go demand other people do what they want. It's a good thing that's a hypothetical situation, and not reality. Free software would die if it were reality. Again, this is a bit long, but sometimes clarity overweights brevity. If I've managed to misunderstand, or misrepresent, what you meant, Svante, please forgive me, and post a explanation to correct me. -- http://gtdfh.branchable.com/ -- GTD for hackers http://obnam.org/ -- HAVE YOU BACKED UP TODAY? -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141023155900.gd4...@exolobe1.liw.fi
Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution
Seconded. 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. > > -- > Regards, > Marga > --- constitution.wml 2016-02-25 08:03:04.0 +0100 > +++ constitution.new.wml 2016-07-08 15:18:41.857474553 +0200 > @@ -37,7 +37,7 @@ > >The Project Leader; > > - The Technical Committee and/or its Chairman; > + The Technical Committee and/or its Chair; > >The individual Developer working on a particular task; > > @@ -69,7 +69,7 @@ > > > A person may hold several posts, except that the Project Leader, > -Project Secretary and the Chairman of the Technical Committee must > +Project Secretary and the Chair of the Technical Committee must > be distinct, and that the Leader cannot appoint themselves as their > own Delegate. > > @@ -460,10 +460,10 @@ > > > > -Appoint the Chairman of the Technical Committee. > +Appoint the Chair of the Technical Committee. > > > - The Chairman is elected by the Committee from its members. All > + The Chair is elected by the Committee from its members. All > members of the committee are automatically nominated; the > committee votes starting one week before the post will become > vacant (or immediately, if it is already too late). The members > @@ -476,10 +476,10 @@ > > > > -The Chairman can stand in for the Leader, together with the > +The Chair can stand in for the Leader, together with the > Secretary > > -As detailed in §7.1(2), the Chairman of the Technical > +As detailed in §7.1(2), the Chair of the Technical > Committee and the Project Secretary may together stand in for the > Leader if there is no Leader. > > @@ -561,10 +561,10 @@ > > Details regarding voting > > -The Chairman has a casting vote. When the Technical Committee > +The Chair has a casting vote. When the Technical Committee > votes whether to override a Developer who also happens to be a > member of the Committee, that member may not vote (unless they are > -the Chairman, in which case they may use only their casting > +the Chair, in which case they may use only their casting > vote). > > > @@ -627,10 +627,10 @@ > > > > -Can stand in for the Leader, together with the Chairman of the > +Can stand in for the Leader, together with the Chair of the > Technical Committee. > > -If there is no Project Leader then the Chairman of the > +If there is no Project Leader then the Chair of the > Technical Committee and the Project Secretary may by joint > agreement make decisions if they consider it imperative to do > so. > @@ -658,7 +658,7 @@ > > If there is no Project Secretary or the current Secretary is > unavailable and has not delegated authority for a decision then the > -decision may be made or delegated by the Chairman of the Technical > +decision may be made or delegated by the Chair of the Technical > Committee, as Acting Secretary. > > The Project Secretary's term of office is 1 year, at which point > @@ -671,7 +671,7 @@ > Developers. > > When acting together to stand in for an absent Project Leader the > -Chairman of the Technical Committee and the Project Secretary should > +Chair of the Technical Committee and the Project Secretary should > make decisions only when absolutely necessary and only when consistent > with the consensus of the Developers. > -- Schrödinger's backup hypothesis: the condition of any backup is undefined until a restore is attempted. -- andrewsh signature.asc Description: PGP signature
Re: Amendment to Proposed GR: Declassifying parts of -private of historical interest
Seconded. On Sun, Jul 17, 2016 at 05:56:12PM -0700, Don Armstrong wrote: > In response to the helpful comments, I've modified my proposed amendment > to Nicolas's resolution by adding "at minimum", and now propose the > following amendment: > > === BEGIN GR TEXT === > > Title: Declassifying parts of -private of historical interest > > 1. The 2005 General Resolution titled "Declassification of debian-private >list archives" is repealed. > > 2. Debian listmasters and/or other individuals delegated by the DPL to >do so are authorized to declassify excerpts of -private of historical >interest by any process which at minimum provides sufficient time and >opportunity for Debian Developers to object by GR prior to >declassification. > > 3. In keeping with paragraph 3 of the Debian Social Contract, Debian >Developers are strongly encouraged to use the debian-private mailing >list only for discussions that should not be disclosed. > > === END GR TEXT === > > -- > Don Armstrong https://www.donarmstrong.com > > There are two types of people in this world, good and bad. The good > sleep better, but the bad seem to enjoy the waking hours much more. > -- Woody Allen -- Schrödinger's backup hypothesis: the condition of any backup is undefined until a restore is attempted. -- andrewsh signature.asc Description: PGP signature
Re: Proposed GR: Repeal the 2005 vote for declassification of the debian-private mailing list
On Thu, Sep 01, 2016 at 11:15:05PM -0500, Gunnar Wolf wrote: > 1. The 2005 General Resolution titled "Declassification of debian-private >list archives" is repealed. If we're going to have another discussion and vote about this, I think it might be good to vote with a full spectrum of choices on the ballot. * Keep debian-private as is. No change to declassification. (This is effectively FD, except it doesn't invite more talk about this.) * Close debian-private entirely. * Close debian-private, but add a debian-vac list instead. * Forbid any declassification. * Allow declassification, ask DPL to find a team by date X to work out a declassification process and vote on that. If no team can be found, fall back on forbidding declassification. * Same, except ask tech-ctte to work out the process. * Allow selective declassification by giving access to a team of external experts (historians, anthropologists, social scientists, etc) to select parts of -private archives and in parallel use one of the above methods to decide on a process to actually declassify the parts that get selected as interesting. * Build a bot that randomly picks messages and asks their authors of messages if they can be declassified. * Whatever else people come up. (I don't expect to participate in this GR further. I might vote.) -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: New amdendment proposal (Re: Proposed GR: Acknowledge difficulty of declassifying debian-private)
On Wed, Sep 21, 2016 at 11:01:50AM +0100, Iain Lane wrote: > 2b. Participants may declassify the material of others where > consent has explicitly been given by the authors of all of the > material being declassified. What about discussions where some of the participants have died? -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: GR proposal: remove obsolete reference to CDs from SC
On Fri, Sep 30, 2016 at 08:04:40PM +0200, Jakub Wilk wrote: > I hereby propose the following GR: > > === BEGIN GR TEXT === > > The following sentence is removed from the Social Contract §5: > > "We encourage CD manufacturers to read the licenses of the packages in these > areas and determine if they can distribute the packages on their CDs." > > === END GR TEXT === > > Rationale: CDs has become largely irrelevant as a medium for distributing > Debian. While we could update the wording to say s/CD/optical medium/ (or > something similar), SC seems like an odd place to give Debian redistributors > legal advice. I second the proposal. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: Proposed GR: State exception for security bugs in Social Contract clause 3
On Tue, Jan 10, 2017 at 07:30:23AM +0100, Moritz Mühlenhoff wrote: > Scott Kitterman wrote: > > Has anyone ever seriously questioned the appropriateness of the > > Security Team's practices based on the Social Contract? > > Not in the last 11 years since I'm around. If that came up before, Martin or > Wichert should know. Man, Debian is just the _worse_ at hiding problems. Security issues? We hide them by announcing them on a dedicated mailing list. Now, it's true that we track security issues in a different, and it's private, which is in contradiction to what the social contract says: We will keep our entire bug report database open for public view at all times. Reports that people file online will promptly become visible to others. I'm not opposed to amending the SC to say that security issues my be kept private for a limited time, but I'm not sure it's worth it. I especially would like to avoid anything that results in nitpicking details, either during a GR or in the future, about what is a security issue, what is a serious issue, and what is a limited time, and what punishments we should have for exceeding a time limit. In my opinion, we already follow the spirit of not hiding bugs. We do publish security issues. If anything, the SC might be amended to not specify details of how we achieve the not-hiding of bugs. For example, we don't track security bugs on bugs.debian.org (which is clearly "our bug database"), but in a separate tracker. Is that a violation of the SC as well? (That's a rhetorical question, and we will now commence a long discussion about it in 3, 2, 1...) As a constitutional document, the social contract should stick to project values, not how to implement those. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: having public irc logs?
(Replies redirected to debian-project, since this has nothing to do with the DPL election anymore.) On Fri, Apr 07, 2017 at 07:51:21AM +, Gianfranco Costamagna wrote: > e.g. I think Release Team channel is useful to know if something bad > is going on, also Ftp channel or Buildd one. e.g. I can spot the > need of a give back, I can check the log to see if it has been > already requested, and then go in the channel to request it. I guestion the usefulness of IRC logs for that kind of thing. The log shows that, say, a package was discussed three hours ago. Has the situation changed? It might have, but without anyone mentioning it on IRC, and therefor in the log. The kinds of things that are discussed on IRC tend be quickly changing. Logs are not useful for those. In my opinion and experience. > I see two scenarios: > 1) now everybody thinks irc is private and privacy protected, so > people are encouraged to "say what they think without doing it in an > appropriate way" > 2) irc becomes publicly logged, and people starts behaving more > appropriately. This does not match my observations of reality. People seem happy to behave quite badly using their own names in public fora as it is. Making IRC channels public is unlikely to have much effect on behaviour. If it did, nobody would be an ass on Facebook, Google+, or Twitter unless they've taken care to hide their identity well. Yet people are posting, using their real names, sexist and racist slurs, even death threats. Not to mention newspapers and TV. If there's a problem with how people behave on IRC, that should be addressed directly. > You want to protect privacy but you know privacy doesn't exist on > public places. I disgree strongly. If I sit on a park bench with a friend and we discuss something, we have an expectation of privacy. If you record our conversation and play it on the radio, you've violated our privacy. > (it would be nice if some removed developer going away after some > bad flame war over Debian would publish *all* the logs just for fun) > How will you protect the privacy then? You're suggesting that someone publish non-public discussions? Becuase it would be fun? Seriously? > People should be responsible for what they say, regardless where > they say. We are not kids anymore. I'll be sending a handyman to install a webcam and microphone in your bathroom and bedroom. I've also engaged a private investigator firm to follow you and record all discussions you have with friends. The ones that mention or refer to Debian will be posted to meetings-archive.debian.net. A team of volunteers will transcribe them and post them to identi.ca. After all, ýou need to be responsible for anything you say, at any time, in any place, in any context. More constructively... if you have a point that specific disucssions about, say, release management should be made more public, then make a specific suggestion about that, with justificiations why it's a good idea. Saying that all Debian IRC channels should be logged publically is too broad to be acceptable to a large number of people. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
DPL: friction in Debian?
A question to the sole candidate: What is the biggest source of friction, in your opinion, in Debian development? What do you propose to do about reducing it? By friction I mean things that do not hinder things, but increases the effort required. For example, having to wait for bts.debian.org spam filtering to process one's new bug report. signature.asc Description: This is a digitally signed message part
Re: DPL: friction in Debian?
On Mon, 2018-03-26 at 22:48 +0300, Lars Wirzenius wrote: > A question to the sole candidate: > > What is the biggest source of friction, in your opinion, in Debian > development? What do you propose to do about reducing it? > > By friction I mean things that do not hinder things, but increases the > effort required. For example, having to wait for bts.debian.org spam > filtering to process one's new bug report. After sleeping on it, I'd like to clarify my question a little. Given that the DPL doesn't actually lead the technical developoment work of Debian, I'd be most interested in non-technical sources of friction. For example, processes, organisational structure, an resource congenstion. signature.asc Description: This is a digitally signed message part
Re: Question: What would you like to see {more,less} of?
On Fri, 2018-03-30 at 16:04 +0100, Chris Lamb wrote: > Dear -vote, > > Due to the absense of the usual tête-à-tête on -vote this year, > to stimulate the conversation further I thought I might pose a > question to the electorate myself. > > Therefore, what would you like to see *more* of from a Project > Leader? What would would you like to see less of? I'd like to see more overt, public intervention when conflicts, "flame wars", happen, and even before things flare up. signature.asc Description: This is a digitally signed message part
Re: Angus Lees for DPL
to, 2005-02-24 kello 13:17 +1100, Angus Lees kirjoitti: > At Wed, 23 Feb 2005 19:48:35 -0600, Graham Wilson wrote: > > On Thu, Feb 24, 2005 at 11:52:08AM +1100, Anand Kumria wrote: > > > I hereby nominate Angus 'gus' Lees as Debian Project Leader (DPL). > > > > Don't developers have to nominate themselves? Or am I mistaken? > > That seems a strange rule. Debian constitution, section 5.2, "Appointment": For the following three weeks any Developer may nominate themselves as a candidate Project Leader. Strange or not, for DPL, developers have to nominate themselves. It is, I guess, the easiest way to make sure no-one is nominated against their wish. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for A. Towns - NM
pe, 2005-03-04 kello 04:21 -0800, Anthony Towns kirjoitti: > I tend to think having a simple "post a non-private > message to -private, and you'll be suspended from the lists for a week, > and followups to the message will be bounced" would be both effective, > and require very little enforcement after the first instance. I suspect this will raise all sorts of paranoia about censorship. Because of this, I suggest it would be particularly important that such decisions are documented (at least for the duration they are in effect) and that there is also a venue that will always be open (say, a new list, debian-unmoderated). Other than that, I think it may prove to be a good thing in the long run to invest some effort in avoiding clutter and flames on our lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
ke, 2005-03-09 kello 17:07 +0100, Michael Banck kirjoitti: > On Wed, Mar 09, 2005 at 03:15:11PM +0100, martin f krafft wrote: > > That said, there is no way to ban flamewars since they are sort of > > part of the nature of a project like this. > > I do not subscribe to this. Flamewars are *not* a necessary evil (or > even a good thing), I believe we would be at least as productive without > them. The Python newsgroup (and corresponding list) comp.lang.python has always seemed to me much friendlier than Debian lists, despite the fact that they are of similar sizes. I claim therefore it is possible to have a big group of people working and talking together even about controversial issues without flames, if the group as a whole considers it a good thing and there are prominent role models that eschew flames and actively calm things down when they get hot. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [followup question] Career path for non-maintainer DD's
to, 2005-03-17 kello 10:00 +, Helen Faulkner kirjoitti: > What use do developers have for the right to vote? Surely if you can > say that someone spending hours translating stuff for Debian doesn't > need to vote you can just as easily say that someone spending hours > maintaining packages doesn't need to vote either. I think it would be fairly reasonable to let translators, documenters, and other people who do good for work Debian, become Debian developers, but only have those who pass a "packaging skills exam" (like T&S is mostly now) have upload priviledges. This would require having two keyrings: one for all DDs, and a subset for those who are allowed to upload as well. I doubt this would be too tedious to maintain, though I might be wrong, since I'm not familiar with the details. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
