Re: GR: welcome non-packaging contributors as Debian project members
On 14.09.10 10:53, Stefano Zacchiroli wrote: Of all those topics, one topic *might* have consensus already: accepting as DDs contributors which have contributed a lot to Debian doing non-packaging work, which intend to continue doing so, and which are ready to uphold our Foundation Documents. My feeling of consensus on that builds upon: in person feedback, private mails, and a growing number of requests on that direction hitting Front Desk (which FD has kindly shared with me). I do have an impression of consensus, but I don't have any "quantitative" evidence. As a discussion alone cannot fix that, here is the draft GR I'm hereby introducing: I don't understand the procedure. You are already empowered to do it: 8.1 The Project Leader's Delegates: 1. [...] 2. may make certain decisions which the Leader may not make directly, including approving or expelling Developers or *designating people as Developers who do not maintain packages*. This is to avoid concentration of power, particularly over membership as a Developer, in the hands of the Project Leader. So you are already free to do it by delegating. A GR would be used to overrule your decision, but, as you already noted, there is already a general consensus on the issue. ciao cate PS: and a personal comment. I think the entire issue is pure technical: who and how to choice the non-maintainer developers, the account settings and machine accesses, the designation, etc. But in Debian style we are writting too much (and in a philosophical level). The decision could do a title on the news, but in reality the real and practical effects are IMHO minimal. ciao cate -- 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/4c8f40be.9050...@debian.org
Re: Bits from the release team and request for discussion
Anthony Towns wrote: On Fri, Jul 31, 2009 at 05:39:23AM +1000, Anthony Towns wrote: On Thu, Jul 30, 2009 at 07:28:58PM +0200, Luk Claes wrote: About freeze timing we think that DebConf should definitely not fall into a freeze We noticed that releases in the first quarter of the year worked out quite well in the past like both Etch and Lenny. Taking these into consideration we think it would be best to freeze in December. We'll be consulting all key teams within Debian to see how their plans and schedules can fit into a new timeline. Before the end of August we hope to have finished this process of consultation and be able to present the new plan to you. Why not have a developer poll as to what month(s) would most suit people for the freeze, rather than limiting it to "key teams"? So, with August almost half-way over, I guess the release team's not going to be doing much more to seek input from non-key teams/developers. I still think it'd be interesting and useful to get broader input, though. Something like a choice amongst the following questions by GR might work: 1. The Debian project recommends that the release team target December 2009 for squeeze's freeze, and work hard to avoid allowing the freeze to slip by more than a few weeks. The project notes this is approximately 10 months after lenny's release, and approximately 18 months after lenny's freeze. The project acknowledges this may assist in synchronising Debian 6.0 and Ubuntu 10.04 LTS, may assist in setting up regular freezes every second December, and is intended to allow Debian 6.0 to be released prior to DebConf 2010. (...) Any thoughts? We could have such a vote over and done in about two weeks, with the DPL's consent, and it'd seem a lot more inclusive and less cabal-tastic than how things seem to be working atm... Later Luk wrote that now December 2009 seems an unrealistic target, but he would talk to other teams to discuss the freeze date/period before announcing again. IMHO we should wait a formal decision of RMs before a GR. Personally I don't think we should do a GR to recommend a freeze or release date. We already used the DPL election to push a release, when it was *long* due, but I don't think we should push a freeze. ciao cate -- 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
Thomas Bushnell BSG wrote: On Wed, 2009-05-13 at 10:53 +0200, Giacomo A. Catenazzi wrote: DFSG is a guideline and a target: we must no go far as the nearest point we reached, but it still a guideline. Consider: - we never had a full DFSG Debian (also when DFSG was written) - we have "RC" also on stable releases. What should we do in such cases? Block all dDbian website, all mirrors, etc. because it is clearly against our foundations? No. The Social Contract does not leave vague how we use the DFSG. It could say that we take the DFSG as a guideline, or as a target, but it does not. "We provide the guidelines that we use to determine (...)" DFSG is that guideline. "Guideline" indicates direction. (note that it is in the sentence, not as acronym) "We promise (...) will be free". *will* indicate a future intention. we must not add more non-free software (but by errors), and we should try to remove non-free (the target). It does not say that we try to abide by it, or that we weigh it against other things; it says that we *do* abide by it, 100%. I wonder, how could it be written even more strongly? So, I think the actual social contract is not so strong. "Debian releases only distributions that contain only softwares, documentations and art-works that is free according to DFSG" would be stronger. But it is very dangerous to have to strict rules: if we found a non-free software (outside the exceptions) in potato o in lenny, do we annihilate because we don't follow the guidelines? As you wrote, there will always bugs, and also wrong attributed code, unchecked licenses, ...; so I would not like to have a stronger statement. I have the feeling that if it said "we will never intentionally include non-free software in Debian, no matter what the circumstances" you would still start telling us that this is a mere statement of goals and intentions, but not anything actually binding. Of *course* there will be bugs. We cannot promise not to make mistakes. The argument is *not* about whether non-free things get in unintentionally. We can't make a promise never to make a mistake. But we can promise not to intentionally include non-free software, and it is this promise which we have now broken twice. We I joined debian, I read that we (DD) was never obliged to do things (but with a kind request to retire gracefully if we cannot improve debian). But I don't find anymore such document. I cannot work on Debian kernel: I've no time and capabilities, so I cannot help reducing such non-free code, but I'm helping in other parts. So what we should do? Never release, because we have no man-power on some complex tasks? But so we throw the other works, where we removed non-free software, and improved freedom. I try to do most as I can do, to have a 100% free Debian, on my packages, and on other packages, but you are telling me that I go to every RC bug and try harder to resolve bugs? [I can do it, but I'm sure it is a waste of time] ciao cate -- 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
Thomas Bushnell BSG wrote: On Tue, 2009-05-12 at 17:06 +0200, Wouter Verhelst wrote: I think this is the core of the disagreement. I do not call it a temporary override of a foundation document; I call it a temporary practical consensus between "the needs of our users" and "the needs of the free software community". I don't understand. Either Social Contract section one and the DFSG prohibit the distribution of a non-free blob in the release, or they do not. If they prohibit it, then it is an override to distribute notwithstanding the prohibition. If they do not prohibit it, then no resolution is necessary. You seem to say an inconsistent thing: that they do prohibit it, and we can avoid that prohibition by calling it a "practical consensus" instead of an "override". Surely, however, it is the effect that matters, and not the label you give it. DFSG is a guideline and a target: we must no go far as the nearest point we reached, but it still a guideline. Consider: - we never had a full DFSG Debian (also when DFSG was written) - we have "RC" also on stable releases. What should we do in such cases? Block all dDbian website, all mirrors, etc. because it is clearly against our foundations? No. Where to put the line? This is the main problem: we have different interpretations and our foundation documents (and related discussions) doesn't provide us a true (and clear) interpretation. So I applaud the recent discussion to rewrite (better, clearer) our foundation documents. ciao cate -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Question: Why do you [not] candidate?
Hello, The question seems very simple: Why do you [not] candidate?, but I'm looking more about: - Why only two candidates ? - Is it good for campaign and discussions? - Why so low interest for DPL? ciao cate -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Another one?
Lucas Nussbaum wrote: Also, I don't think we that are there yet: maybe objections against Joerg's decision^Hproposal were raised but not addressed (not only on the process that Joerg followed, but also on the content of his proposal). Also, we have alternative proposals (Lars' and Raphael's). Couldn't we wait until after the release to have a big discussion about membership status ? And then have a GR to vote on the various proposals? Adding new man-power, but not allowing DD to fully improve Debian? ;-) We should finally agree and implement your NMU guidelines. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DAM has no competency to make changes to membership structure
Joerg Jaspert wrote: On 11551 March 1977, martin f. krafft wrote: The changes announced the 22nd of October on the debian-devel-announce mailing list (Message-id: <[EMAIL PROTECTED]>) are suspended [§4.1(3)]. This suspension is effective immediately [§4.2(2.2)]. I do not understand why we need to do this at all. According to [0], Joerg has been "empowered to create and remove developer accounts according to the New Maintainer procedure." He has not been empowered to introduce new membership classes or restructure membership in any other way. I think this was the big error on Joerg proposal: giving different names (classes) to non-maintainer developers. If we call the non-maintainer developers (the DME) DD, all the proposal fits without doubts in the current structure. It would be one more change of NM procedure, as we had in last years. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Release goal: MUA (and MTA) should allow to send debian votes
A strange release goal, but I think it deserve to be done, both for public image, and for us ;-) For lenny: - MUA (and MTA) that support UTF-8 and GPG should support combination of both, so that they can be used to vote on debian vote system. And I propose that we open some fake vote, to test voting MUA and voting system. I would prefer two tests: one with European characters (8-bit), and an other with other (Asiatic characters) For the after-lenny release: - MUA (and MTA) should (if possible) support UTF-8 and GPG (and they combination) for all usages. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Keep non-free
Martin Schulze wrote: Andreas Barth wrote: * Martin Schulze ([EMAIL PROTECTED]) [040226 08:55]: We cannot include it in Debian anyway, since it is non-free. If Debian stops distributing it but people will build ftp.non-free.org, what's the different from the users' perspective? A new apt-line. Oh horror... What do we gain from replacing non-free on Debian with ftp.non-free.org? ftp.non-free.org would not have to be maintained by Debian, contrary to ftp.debian.org. BTW I registred non-free.org for such cases (and nonfree.org is registred by Perens) ciao cate
Re: Proposal: Keep non-free
Martin Schulze wrote: Andreas Barth wrote: * Martin Schulze ([EMAIL PROTECTED]) [040226 08:55]: We cannot include it in Debian anyway, since it is non-free. If Debian stops distributing it but people will build ftp.non-free.org, what's the different from the users' perspective? A new apt-line. Oh horror... What do we gain from replacing non-free on Debian with ftp.non-free.org? ftp.non-free.org would not have to be maintained by Debian, contrary to ftp.debian.org. BTW I registred non-free.org for such cases (and nonfree.org is registred by Perens) ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [atlarge-discuss] online voting
Steve Langasek wrote: On Thu, May 16, 2002 at 03:01:38PM +0200, Vittorio Bertola wrote: > So, to apply this system to ICANN, we would have to build the At Large membership by cooptation, ie each new member would have to be introduced by another one. This could be somewhat interesting, but I guess it could be not open enough for our scale and purposes. Debian has chosen this particular method because it's consistent with our goals as a community: a PGP web of trust maps closely onto the relationships that have to exist among us as developers of an operating system. For ICANN, I'm pretty sure that this does not apply; so requiring all PGP keys to be signed by someone already in ICANN is probably not the way to go about it. You can choose a different method that provides the right balance of security and convenience for your organization. You might accept PGP keys with only email verification, you might accept them printed out and sent by normal mail, you might accept keys that have been signed into the global web of trust. Each approach offers a different degree of authenticity, and carries with it a different degree of overhead. Debian can use PGP because the target are the developers. I think the target of ICANN is larger (and also less tecnical), thus using PGP is not an option. (People will not enter in @large or they will use PGP in a unsecure manner, giving trust problems to all PGP infrastructure. ciao giacomo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [atlarge-discuss] online voting
Steve Langasek wrote: > On Thu, May 16, 2002 at 03:01:38PM +0200, Vittorio Bertola wrote: > >>So, to apply this system to ICANN, we would have to build the At Large >>membership by cooptation, ie each new member would have to be >>introduced by another one. This could be somewhat interesting, but I >>guess it could be not open enough for our scale and purposes. > > > Debian has chosen this particular method because it's consistent with > our goals as a community: a PGP web of trust maps closely onto the > relationships that have to exist among us as developers of an operating > system. For ICANN, I'm pretty sure that this does not apply; so > requiring all PGP keys to be signed by someone already in ICANN is > probably not the way to go about it. You can choose a different method > that provides the right balance of security and convenience for your > organization. You might accept PGP keys with only email verification, > you might accept them printed out and sent by normal mail, you might > accept keys that have been signed into the global web of trust. Each > approach offers a different degree of authenticity, and carries with it > a different degree of overhead. Debian can use PGP because the target are the developers. I think the target of ICANN is larger (and also less tecnical), thus using PGP is not an option. (People will not enter in @large or they will use PGP in a unsecure manner, giving trust problems to all PGP infrastructure. ciao giacomo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
