Re: GR Proposal 2: Declassification of -private
On Fri, Nov 18, 2005 at 04:09:58PM +1000, Anthony Towns wrote: Thus, I propose that the Debian project resolve that: --- In accordance with principles of openness and transparency, Debian will seek to declassify and publish posts of historical or ongoing significance made to the Debian Private Mailing List. This process will be undertaken under the following constraints: * The Debian Project Leader will delegate one or more volunteers to form the debian-private declassification team. * The team will automatically declassify and publish posts made to that list that are three or more years old, with the following exceptions: - the author and other individuals quoted in messages being reviewed will be contacted, and allowed between four and eight weeks to comment; - posts that reveal financial information about individuals or organisations other than Debian, will have that information removed; - requests by the author of a post for that post not to be published will be honoured; - posts of no historical or other relevance, such as vacation announcements, or posts that have no content after personal information is removed, will not be published, unless the author requests they be published; - comments by others who would be affected by the publication of the post will also be taken into account by the declassification team; - the list of posts to be declassified will be made available to developers two weeks before publication, so that the decisions of the team may be overruled by the developer body by General Resolution, if necessary -- in the event such a resolution is introduced (ie, proposed and sponsored), the declassification and publication of messages specified by the resolution will be deferred until the resolution has been voted on. --- I second this proposal. Kurt pgpz60S4wFHRg.pgp Description: PGP signature
Re: Reflections about the questions for the candidates
On Sun, Mar 05, 2006 at 03:11:58AM +0100, Enrico Zini wrote: But there's more than that. In the last year as part of the DPL Team, people have been criticising the last year for the lack of reports. But I don't remember a single one sending in a mail like Dear DPL[-Team], what happened last week?. There was no contact address for the DPL-team, or atleast none that I know off, so it's rather hard to ask them. The only available address that I know of is [EMAIL PROTECTED] And as far as I know, there wasn't even an official list of who was in the team. I did mail [EMAIL PROTECTED] several times about the lack of DPL reports and related questions and the first time this resulted in mail to debian-devel-announce, and as far as I know, that was his last DPL report. After some other mails he said we should follow what he's doing on planet.debian.org, which I disagreed with, and said so. I don't blame the DPL team for this, it's the DPL that in the end is responsible for it. Kurt -- 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
On Tue, Aug 22, 2006 at 03:18:04PM -0700, Steve Langasek wrote: THE DEBIAN PROJECT therefore, 1. reaffirms its dedication to providing a 100% free system to our users according to our Social Contract and the DFSG; and 2. encourages authors of all works to make those works available not only under licenses that permit modification, but also in forms that make such modifications practical; and 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. I'm a little confused as to what this means exactly. Point 2 seems to say that we consider source to be such a form of the work that modifications are practical, but without actually saying anything. However, I think such a definition of source would be a good thing. But this point really doesn't say much about Debian, it just says we encourage others to do something. So I don't see why this belongs in the GR in the first place. Point 3 then seems to go the other way around and say we don't need sources for of few types of works. My main problem with this is that still a little vague about which types of works don't require source. I guess point 4 is saying the firmware should be considered the same as the other works in point 3 and the source isn't needed for firmware. However, it doesn't say anything about other points of the DFSG. So we should still need a license that allows atleast derived works. And I don't see how we're going to make derived works of firmware without the source for it. Kurt -- 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
On Thu, Aug 24, 2006 at 05:08:33PM -0700, Steve Langasek wrote: On Thu, Aug 24, 2006 at 08:29:49PM +0200, Kurt Roeckx wrote: On Thu, Aug 24, 2006 at 01:16:42AM -0700, Steve Langasek wrote: Point 3 then seems to go the other way around and say we don't need sources for of few types of works. My main problem with this is that still a little vague about which types of works don't require source. What problems do you consider this vagueness to cause? What changes would you suggest to make this less vague? It lists images, video, and fonts. And I'm assume it's going to cover more than just that. I'm also not sure that this is something we want for all types of data. I think we *want* the best possible form for modification for all types of data. I don't think the DFSG *requires* this, and therefore I don't think *we* should require it. Do you disagree? I think we should require it. The DFSG says we need the source, and I understand that as the best possible form for modification. For instance, bison/yacc generates a C file. You could consider that C file a source, but it's not. We want the original file that was used to generate that C file. There might be several layers of tools that are used to generate an object file from it's source, but it's the source we want. For instance when they're raster images or fonts, I'd rather have the source, if there ever was a vector based format of it. But I don't care if there never was a vector based format, so nothing that would be a more prefered way of changing it. Rather have != Insist on for inclusion in main, though? No, I would insist on having it. Anyway, the answer I had in mind was a hex editor or a decompiler. If the firmware in question *is* code, and we know what the chip in question is that the code is running on, both options seem within the realm of plausibility to me. No, of course they're not the *ideal* means of editing such a work, but AFAIK most firmware is on the order of what programmers used to program directly in assembly, so it's also not totally *insane* to try to edit such a binary directly as it would be for most modern userspace apps, for instance.) I don't see a hex editor useful for much, and a decompiler only slightly better. If a decompiled version was useful to do derived work, it would be the same as source, so not requiring source doesn't make sense to me. The difference with source is that you actually have names of functions and variables, you have comments with it. Those things make it easy to understand what it's trying to do. So it's easier to make changes too. OTOH, the source may require a non-free tool to render it into a binary firmware form. If you don't have that tool, and maybe even no hope of getting access to it, is it any longer evident that the source is more useful than the binary for derived works? Yes, from there we get into discussions about defining source as whatever form people prefer to work from -- hmm, redefinition? -- and whether we can ship anything in main that we don't have a full toolchain for; but a) is that actually required by the DFSG, and b) is that the right standard to set, either today or in the future? The DFSG doesn't say that the toolchain should be available for it to be free, and it shouldn't. But I understand the SC as requiring it to be included in main. It's also one of the reasons we have such a thing as contrib. There was a time when alot of java applications were in contrib because there wasn't anything in main we could use them with. But those were free software. You just needed non-free software for it to be useful. And now most, if not all, have moved to main. It would also be useful to have a list of firmwares we're currently are talking about, and what license they have. Are there any that only fail DFSG 2, or will this part of GR have no effect at all? Larry Doolittle has prepared a very helpful table at http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html. A number of these are marked as being under a BSD-ish license, which would qualify; a number of others are listed as GPL but sourceless, which nominally makes them non-distributable, but it seems unlikely that any copyright holders on these would refuse to relicense under more appropriate terms even if they weren't willing/able to release source. So, from that list: * 46 source files that already use request_firmware() or mod_firmware_load() * 18 already removed from Debian (linux-2.6_2.6.17.orig.tar.gz) * 47 apparently nondistributable * 12 apparently ok for non-free * 14 free So, we have a total of 137 drivers that require firmware. We have 14 that are free and can stay in main in any case. I'm not sure about those 46 that already use request_firmware(), but we seem to have atleast 12 (BSD-ish) that could go to non-free
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
On Mon, Sep 18, 2006 at 10:07:18PM -0700, Don Armstrong wrote: D. Requests that vendors of hardware, even those whose firmware is not loaded by the operating system, provide the prefered form for modification so that purchasers of their hardware can exercise their freedom to modify the functioning of their hardware. What I also find important is that hardware comes with good technical documentation, so that we can either write the software ourself, or modify what the hardware vendor provides. But I'm not really sure if this belongs in a GR, and how it should be put into it. We might want to do things with the hardware that the vendor did not design it for. For instance, most GPUs would be very useful doing vector math. It can do alot more FP operation than a normal CPU, and things like that. I need to look at what the other current proposols look like, but I think a combination of this with the apoligy might be a good proposol. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [AMENDMENT] Now is not the time to decide on firmware issue
On Tue, Sep 26, 2006 at 06:18:37PM +0200, Frans Pop wrote: The Debian Project: (a) Affirms that the project strives for and encourages 100 percent free software, including the availability of source for all types of files. So, we strive for 100% free software, whatever software might mean in this case. But then you say there needs to be source available for all types of files, which would include things like firmware, logos, images. So, this part seem to be about the same as Don's proposol? Maybe I'm misunderstanding this part? (b) Resolves that the project needs more time before a decision can be made on how sourceless firmware or other types of files (such as, but not limited to, logos, images and video) are to be dealt with. But here you seem to be saying the opposite, and that we need further discussion for some of those types of files. I'm lost at what you're trying to do with this. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes (Was: kernel firmwares: GR proposal)
On Wed, Sep 27, 2006 at 11:36:37AM +0200, Frederik Schueler wrote: Hello, On Tue, Sep 26, 2006 at 04:02:11PM -0700, Steve Langasek wrote: As I mentioned previously, I don't think point 3. here is the compromise I would like to see. Without further conditions is so broad that it seems to even *require* us to include firmware in main that lacks any sort of proper distribution license. The intention is indeed to release the kernel as-is for Etch, postponing the work which needs to be done in contacting vendors and upstream to get relicensings and source disclosures until after the release. And indeed, the upload of a completely unpruned 2.6.18 package to unstable suggests that this is not an accident of wording, but the actual view of the present kernel team. It is at least my actual view, the others should speak for themself. From your proposol: 2. We acknowledge that there is a lot of progress in the kernel firmware issue; however, it is not yet finally sorted out; So, what progress has been made? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes (Was: kernel firmwares: GR proposal)
On Thu, Sep 28, 2006 at 05:02:13PM +0200, Frederik Schueler wrote: Hi, On Wed, Sep 27, 2006 at 06:40:41PM +0200, Kurt Roeckx wrote: 2. We acknowledge that there is a lot of progress in the kernel firmware issue; however, it is not yet finally sorted out; So, what progress has been made? For example: - the firmware_class infrastructure has been added in more than 100 drivers (as of 2.6.17) So, does that mean that the firmware for those devices isn't part of the kernel source, but lives in non-free somewhere? Or what exactly does this mean? - the qla2xxx firmware has been dropped from the kernel sources, and is now shiped on ftp.qlogic.com - new drivers for devices requiring a firmware to be uploaded during initialization are included without embedded firmware (for example the ipw3945 driver, or aic94xx which has just been added in 2.6.19-rc) So those drivers should go to non-free? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: seconds searched for override of resolution 007 needed. (Was: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.)
On Sun, Oct 15, 2006 at 10:07:02AM +0200, Sven Luther wrote: Hello, Ok, since the proposal in its amended by Manoj form passed, we need to add an amendment to this proposal, accordying to Manoj, so that we don't have two proposals in effect at the same time, leaving it a full mess. Which 2 proposals are in effect that conflict? We only had 1 vote on this as far as I know, so I don't see how it can conflict. So, i propose this amendment, as discussed with Manoj, and need your seconds on this one too. === START OF PROPOSAL === [...] 5. We further note that some of these firmware do not have individual license, and thus implicitly fall under the generic linux kernel GPL license. We will include these firmware in Debian Etch and review them after the release. Vendors of such firmware may wish to investigate the licensing terms, and make sure the GPL distribution conditions are respected, especially with regards to source availability. 6. We will include those firmware into the debian linux kernel package as well as the installer components (.udebs) used by the debian-installer. END OF PROPOSAL Only change, is the addition of clause 0. which states the override. I am not totally satisfied by this text, so if someone has a better idea, it would be nice. Atleast points 5 and 6 aren't in GR we voted on either. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: seconds searched for override of resolution 007 needed. (Was: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.)
On Sun, Oct 15, 2006 at 11:08:13PM +0200, Sven Luther wrote: This is a new proposal, which was not in the ballot, because Manoj hurried the election along the way, while he knew the kernel team was working on a better proposal. Please do not blame our secretary for following the constitution. You only have yourself to blame that it didn't make it on the ballot. Have you actually read the resolution which was voted ? Have you voted for it, and if so i am interested in knowing what you thought you where voting for. Yes I voted for it, and no I didn't read any of the proposals, I just placed some random numbers in front of the choises. But I did not compare what we voted on and your proposol, I wrongly assumed that you were talking about that, so it made little sense to me. I'm sorry if I don't always read what you say, you tend to write too much, and repeat yourself too much, and I don't have the time to read it and find out what changed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[AMENDMENT] Re: seconds searched for override of resolution 007 needed.
I want to amendment the following proposal: === START OF PROPOSAL === Definition: For the purpose of this resolution, the firmware mentioned below designates binary data included in some of the linux kernel drivers, usually as hex-encoded variables and whose purpose is to be loaded into a given piece of hardware, and be run outside the main memory space of the main processor(s). 0. This resolution overrides the resolution just voted (http://www.debian.org/vote/2006/vote_007). 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, both upstream and in the debian packaging; however, it is not yet finally sorted out. 3. We give priority to the timely release of Etch over sorting every bit out; for this reason, we will treat removal of problematic firmware as a best-effort process, and in no case add additional problematic material to the upstream released kernel tarball. 4. We allow inclusion of such firmware into Debian Etch, even if their license does not normally allow modification, as long as we are legally allowed to distribute them. 5. We further note that some of these firmware do not have individual license, and thus implicitly fall under the generic linux kernel GPL license. We will include these firmware in Debian Etch and review them after the release. Vendors of such firmware may wish to investigate the licensing terms, and make sure the GPL distribution conditions are respected, especially with regards to source availability. 6. We will include those firmware into the debian linux kernel package as well as the installer components (.udebs) used by the debian-installer. END OF PROPOSAL And replace the text with: BEGIN OF PROPOSAL We, the Debian project, find freeness that we want for firmware used by the kernel is an important question, and that we will have to deal with this. However, we think that we as a project need more time to deal with it, and having more general resolutions isn't going to solve this. Therefor we will not have another general resolution about firmware until after the release of etch and atleast 6 moths have passed since this general resolution. This does not mean we will not discuss this issue, or work on getting things better. END OF PROPOSAL I'm open for suggestions on how to better word this. Kurt signature.asc Description: Digital signature
Re: First draft of review of policy must usage
On Wed, Oct 25, 2006 at 01:49:03PM -0500, Manoj Srivastava wrote: p - Packages involving shared libraries should be split up into + Packages involving shared libraries ought to be split up into several binary packages. This section mostly deals with how this separation is to be accomplished; rules for files within - the shared library packages are in ref id=libraries instead. + the shared library packages are in ref id=libraries + instead. /p sect id=sharedlibs-runtime I think the should there was good. This is something I want to discuss further. Consider the case where there is a package with a set of, say, 20 binaries with a lot of common code, and upstream decided to abstract it out into a shared lib. This is a shred lib used by anyone else, and it is changing rapidly enough that there is the equivalent of a soname change on every upload. There is no interest in supporting older versions, or even having multiple versions of that lib. In this case, either we can make packaging that software hard (since moving the lib out of /usr/lib etc may involve some work), or we allow some packages to include share libs in the package. I don't know which way one should lean, so I decided to go the route of fewer bugs. If it's not supposed to be used by an other package, it should be moved to /usr/lib/package/. If it doesn't contain any other libraries in /usr/lib, it shouldn't provide a -dev package. So there really isn't a need for a seperate lib package either. Anyway, that's why it says should in the first place, and I don't see why it needs to be changed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First call for vote on immediate vote under section 4.2.2
On Sun, Oct 29, 2006 at 11:13:06AM +0100, martin f krafft wrote: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 2808c3bb-6d17-49b6-98c8-c6a0a24bc686 [ 0 ] Choice 1: The DPL's withdrawal of the delegation remains on hold pending a vote [ 0 ] Choice 2: The DPL's withdrawal of the delegation stands until a vote - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- I don't actually know whether 0/0 is as invalid as I want it to be, but we'll see. You can basicly rank those 2 options the same using either: -- 11 22 The rest should get rejected. But as far as I know, it's just the same as not voting. And I'm not sure what you think an invalid vote would have as effect. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First call for vote on immediate vote under section 4.2.2
On Sun, Oct 29, 2006 at 04:57:46PM +0100, martin f krafft wrote: also sprach Kurt Roeckx [EMAIL PROTECTED] [2006.10.29.1613 +0100]: But as far as I know, it's just the same as not voting. And I'm not sure what you think an invalid vote would have as effect. In voting systems with a quorum, an invalid vote increases the number of cast votes and thus makes it less likely for an option to reach the quorum (which is expressed as a percentage). Please correct me if I am wrong. This vote doesn't even have an quorum, according to the constitution. In the Condorcet system, I guess voting equally for all options has the same effect. Or maybe not, since I may also add to the quorum as the vote is valid. As far as I know, in our voting system each option needs to reach a quorum over the default option to be considered. The total number of votes doesn't matter. If you vote equal or lower than the default option, it doesn't add to the quorum. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [GR] DD should be allowed to perform binary-only uploads
On Thu, Feb 08, 2007 at 06:00:15PM +0100, Bill Allombert wrote: --- The Debian project resolves that Debian developers allowed to perform combined source and binary packages uploads should be allowed to perform binary-only packages uploads for the same set of architectures. --- I have no idea what you're trying to say or do with this. I've already seen various interpretations, and I'm still not sure what you want to do. The way I read this is, if I'm allowed to do src+i386 and src+amd64, (and src+all) upload, I can do a binary-only upload of both i386 and amd64. But afaik, there currently isn't any restriction at all that I for instance do an src+arm upload. Which would mean that with your GR I could do a binary-only upload for any arch. Anyway, I suggest you start with what you want to change. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [GR] DD should be allowed to perform binary-only uploads
On Sat, Feb 10, 2007 at 03:27:25PM +0100, Frank Küster wrote: Steve Langasek [EMAIL PROTECTED] wrote: The error rate on requeue requests that reach me is significant, even from people who are well-informed and involved in the process (e.g., fellow release-team members). Maybe they're less cautious because they know I vet all requests, but I would expect that opening dep-waits/requeues up to the general dev population would result in a *lot* of unnecessary rebuild tries, stuck packages holding up transitions, etc., because the average developer simply isn't clued in on this stuff. Heck, before m68k was dropped as a factor in package propagation into testing, I was routinely finding bogus dep-waits set by the m68k buildd maintainers themselves, and that's only about a half-dozen people. I can name you the reasons why I don't have much of a clue about this (I think): - it wasn't part of the NM TS process, IIRC; all the technical details of testing propagation, freeze/unblock/, and general release team work were a bit meager maybe. In the NM process, you're not expected to learn about everything in Debian. It's about what you as a normal DD need to know. If you want to do release team work, that's something you'll have to learn, and it's actually not that hard to learn. - it's not easy to see what's going on there, and why. For example, I don't know where I can read what dep-wait means and why and how a package is put in this state. I think I know what it means and why it needs to be put there (manually), but that's just because it seems logical. And although I'm not the most involved developer, at least I once setup a buildd and read about wanna-build (about two years ago, forgot all...). So you do know that there exist documentation about wanna-build. It Anyway, it's all at: http://www.debian.org/devel/buildd And the states itself: http://www.debian.org/devel/buildd/wanna-build-states - What's the contact point for asking for dep-wait or requeue? I guess it's that famous bunch of addresses that's also known for getting no response, and when you want to learn something, an occasional thanks, it seems you've grasped the principle or Thanks, but you missed the following is very helpful. I think in most cases you don't request dep-waits and let the buildd admin deal with that itself. It's probably easier to just wait until the dependencies are available and then request it to be requeued. But [EMAIL PROTECTED] is the right place for any such requests. Of course it's difficult to change that. Someone should write a nice page about it, and someone is, as usual, a synonym for not me. So, which parts do you think aren't documented properly? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [GR] DD should be allowed to perform binary-only uploads
On Wed, Feb 14, 2007 at 11:31:17AM +0100, Florian Weimer wrote: * Hamish Moffatt: Do you think it's likely that it can boot the kernel and run the build environment without crashing, but produce broken binaries? We've got a few cases where emulated builds on amd64, sparc64 and s390x failed to produce working binaries for i386, sparc and s390. Usually, these are considered bugs in the affected packages. And what exactly is this emulation? It's just running the 32 bit application on the 64 bit arch? There are packages that have a problem if you run them on a 64 bit arch will try to build things for a 64 bit arch. This is mostly because they process the output of uname, and they should be using dpkg-architecture instead. This can also be worked around by using linux32 to change the output of uname -m. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DPL 2007
On Fri, Feb 23, 2007 at 05:16:34PM -0600, Debian Project Secretary wrote: Hi, Am I the only one having problem authenticating the signature on this mail? I have the same problem. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Mon, Mar 10, 2008 at 10:45:25PM -0700, Russ Allbery wrote: Anthony Towns [EMAIL PROTECTED] writes: or the tech-ctte's involvement in technical improvement of Debian before a conflict exists. Well, with my Policy delegate hat on, I'd certainly welcome more help in that area, but on the other hand I'm not sure I see any specific need for the tech-ctte as such to get involved. What's needed here more than anything else is simply more *people* who are actively doing more *work*, not more formal authority. For example, there are currently insufficient Policy proposal reviewers active on debian-policy to even reach seconding thresholds on anything other than the most obvious or important proposals. Some of this problem rests with me for not more actively soliciting help. I'm working on fixing that, although currently I prioritize my work as a Lintian maintainer over my work as a Policy delegate and Policy has been losing to Lintian frequently lately. I think for most people it's unclear what the status of the various bugs/proposals is. I think the recent changes to the BTS you did should atleast make it more clear. I also think that the process is not clear to everybody. There is an policy-process.txt, but that doesn't seem to be current. From Anthony's mail about the delegation: | AIUI, they'll be updating the policy-process document fairly soon to | make it clear how other people can contribute to policy, and I believe | that at least Russ and Marga will be spending some time doing some more | routine policy tasks to improve their understanding of policy related | issues. I know some other folks have already expressed interest in helping | out on policy related tasks, and I'm pretty sure the policy team would | appreciate your assistance, and be glad to offer suggestions on what | forms your help might take. [...] | only includes the authority to create policy [...] | In so far as I was concerned that the policy delegation was being | used to avoid working towards a consensus on technical policy, I've | been reassured by subsequent discussion both on the -project and -vote | lists and off-list that no one has any intention of letting that happen. | The new policy team have my full confidence and support in their technical | decisions and in their ability to help others contribute to policy, | both individually and collectively. I think if you asked for some help where you need it, people will try and help. It's just unclear to me how I can help. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Secretary? Delegate? [Was: Draft ballot for Proceedural Vote: Suspension of the changes of the Project's membership procedures.]
On Mon, Oct 27, 2008 at 07:28:43PM +, Neil McGovern wrote: Hi all, As 2K developers have now seconded this GR, and the GR itself calls for a suspension of a Delegate's decision, an immediate procedural vote is called for if the decision is to stand while the GR process is followed, as per 4.2.2 of the constitution. Has something changed to who is now the secretary? Did I miss some announcement? Atleast the webpage still mentions Manoj as secretary, and I saw a mail from [EMAIL PROTECTED] with his key. Or is Manoj is still the secretary and did he delegate something to you? What got delegated exactly in that case? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Draft ballot for Proceedural Vote: Suspension of the changes of the Project's membership procedures.
On Mon, Oct 27, 2008 at 07:28:43PM +, Neil McGovern wrote: Attached below is the draft ballot for this proceedural vote. Please send comments to myself 24h before voting opens. You have a total of 3 times proceedural instead of procedural in this mail. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Draft ballot for Proceedural Vote: Suspension of the changes of the Project's membership procedures.
On Mon, Oct 27, 2008 at 09:49:33PM +, Neil McGovern wrote: On Mon, Oct 27, 2008 at 10:23:37PM +0100, Gaudenz Steinlin wrote: On Mon, Oct 27, 2008 at 07:28:43PM +, Neil McGovern wrote: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- a1ea0fab-9ff7-4466-a951-99c712df8192 [ ] Choice 1: Decision on membership reform stands until GR decided [ ] Choice 2: Decision on membership reform delayed until GR decided [ ] Choice 3: Further discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- What does Further discussion mean in the context of this vote? I think there should be no Further discussion on the ballot, as it is not clear what would happen if Further discussion wins. Would the decision still be suspended or not? If Further discussion wins, the decision remains delayed[0]. I thought about removing it, but it's inclusion serves as a 'I abstain' or a 'I think this vote is rubbish' or similar. I can either drop it, or include a bit of text in the ballot about what outcomes mean if you like. Neil [0] It's delayed at the moment. This is a vote to override that essentially. So what is the difference between 2 and 3? In case of 2 we already agree to have an other GR? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Draft ballot for Proceedural Vote: Suspension of the changes of the Project's membership procedures.
On Mon, Oct 27, 2008 at 11:20:30PM +0100, Gaudenz Steinlin wrote: Hi Neil Thanks for the prompt clarification. On Mon, Oct 27, 2008 at 09:49:33PM +, Neil McGovern wrote: On Mon, Oct 27, 2008 at 10:23:37PM +0100, Gaudenz Steinlin wrote: On Mon, Oct 27, 2008 at 07:28:43PM +, Neil McGovern wrote: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- a1ea0fab-9ff7-4466-a951-99c712df8192 [ ] Choice 1: Decision on membership reform stands until GR decided [ ] Choice 2: Decision on membership reform delayed until GR decided [ ] Choice 3: Further discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- What does Further discussion mean in the context of this vote? I think there should be no Further discussion on the ballot, as it is not clear what would happen if Further discussion wins. Would the decision still be suspended or not? If Further discussion wins, the decision remains delayed[0]. I thought about removing it, but it's inclusion serves as a 'I abstain' or a 'I think this vote is rubbish' or similar. Then basically Choice 2 and 3 are the same. I think you could also express 'I abstain' by not ranking any choices at all. But as long as everybody agrees on what happens if either of the options wins, this is only a minor problem. I can either drop it, or include a bit of text in the ballot about what outcomes mean if you like. I would like an explanaiton on the ballot to avoid confusion. It seems to me that what has been proposed and sponsored is option 2, and the constitutions seems to say that a GR should follow in that case. I see no reason to have option 1 on the ballot. I assume if option 2 passes that a discussion period of 2 weeks will follow this procedural vote? I also assume that that GR already has 1 option on it, what Joerg's mail announced. I think option 3 means the same as option 1. The decision stands and we can later overrule it by a full GR if we want. Or does option 1 mean that we'll also have this 2 week discussion period followed by a full GR? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Draft ballot for Proceedural Vote: Suspension of the changes of the Project's membership procedures.
On Tue, Oct 28, 2008 at 12:58:19AM +0200, Kalle Kivimaa wrote: Kurt Roeckx [EMAIL PROTECTED] writes: I think option 3 means the same as option 1. The decision stands and we can later overrule it by a full GR if we want. Or does option 1 mean that we'll also have this 2 week discussion period followed by a full GR? It's the reverse. The sponsorship of 2K people automatically put the DAM decision on hold, and the vote needs to override that automation. Thus the FD choice is the same as the decision stays on hold. This vote is 4.2.2.4: 4. If the decision is put on hold, an immediate vote is held to determine whether the decision will stand until the full vote on the decision is made or whether the implementation of the original decision will be delayed until then. There is no quorum for this immediate procedural vote. I had to read this a few times. But now my understanding is that the decision is on hold until the procedural vote, and that it will be followed by a GR. The procedural vote just says if the decision stands or is put on hold between the procedural vote and the GR. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Draft ballot for Proceedural Vote: Suspension of the changes of the Project's membership procedures.
On Mon, Oct 27, 2008 at 07:28:43PM +, Neil McGovern wrote: =DRAFT=DRAFT=DRAFT=DRAFT=DRAFT=DRAFT=DRAFT=DRAFT=DRAFT=DRAFT=DRAFT=DRAFT= Voting period starts 00:00:01 UTC on Sunday,02nd Nov 2008 Votes must be received by 23:59:59 UTC on Saturday, 15th Nov 2008 So when is this vote going to start? Not that I want one, but it seems to be taking alot of time to have an immediate vote. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware (was: on firmware (possible proposal))
On Fri, Nov 14, 2008 at 09:12:25PM +0100, Peter Palfrader wrote: | Therefore the Debian project resolves that | a) firmware in Debian does not have to come with source. While we do | prefer firmware that comes with source and documentation we will not | require it, | b) we however do require all other freedoms that the DFSG mandate from | components of our operating system, and So do the licenses for all those blobs we have now comply with the DFSG other than that we don't have the source for it? Does this mean that even if the blob is GPL'd, we don't need sources for it? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bundled votes and the secretary
On Mon, Dec 15, 2008 at 09:58:09AM +0100, Pierre Habouzit wrote: from http://www.debian.org/vote/2006/vote_007#majorityreq 4. We give priority to the timely release of Etch over sorting every bit out; for this reason, we will treat removal of sourceless firmware as a best-effort process, and deliver firmware in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Etch, as long as we are legally allowed to do so, and the firmware is distributed upstream under a license that complies with the DFSG. and from the current vote: 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. Now explain to me how a genuine interpretation of the Constitution let the former need simple majority and the latter super majority. The biggest difference is the under a license that complies with the DFSG part. There is also the udeb part that's different. Note that we also have the an option (choice 5) with the under a license that complies with the DFSG part and that doesn't have the 3:1 majority requirement. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
New section for firmware.
Hi, I've been thinking about this proposal for some time, and I probably should have send this some time ago. At least some people seem to have had simular ideas, so I wonder why nobody propsed anything like this. The idea is to create a new section that contains files like firmware images and FPGA data that gets written to the hardware to make it fully functional. It is not meant for drivers that run on the host CPU. The new section should also be available on our CD/DVD images, so that users can just take a CD/DVD and that it works without having to search for the needed firmware and provide it on an other medium to the installer. As draft I'd like to propose: 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We'll create a new area in our archive that contains files like firmware images and FPGA data that gets written to the hardware to make it fully functional. The files in this area should not comply with the DFSG #2, #3 and #4, but should comply with the rest of the the DFSG. 3. This new section will be available on our CD, DVD and other images. I'm open for suggestions on how to better word this proposal, or other changes. The social contract now lists non-free and contrib. I'm not sure if we need to change the SC or not with this proposal. This is meant as a long term solution. The proposal is not about the Lenny release, but I wonder which requirements we should have for files in the new section. And I think if we want it to be able to put it on the CD/DVD, the requirements from the DFSG other than #2, #3 and #4 seem to make most sense. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
On Tue, Dec 23, 2008 at 03:34:29PM +0100, Loïc Minier wrote: On Tue, Dec 23, 2008, Kurt Roeckx wrote: The idea is to create a new section that contains files like firmware images and FPGA data that gets written to the hardware to make it fully functional. It is not meant for drivers that run on the host CPU. Do you propose to include data for which we only lack source or build tools or doc? Or would it also include firmware data which has a license preventing any modification to the contents of the data? It did say that it shouldn't comply with DFSG #3, so that would mean it can prevent modification. If the intent is to include it in our CD-ROMs, I think some people will want a really really free CD-ROM which doesn't have this section. So that would mean two sets of images. What is the advantage of this section over pulling firmwares from non-free into a second set of images? CDs with firmware from non-free on it would be unofficial CDs, since non-free isn't part of Debian. So I assume non of our pages would have a link to that. I want official CD images with the firmware on it. I'm open for other suggestions on how to reach that goal. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
On Tue, Dec 23, 2008 at 07:02:27PM -0600, Peter Samuelson wrote: [Kurt Roeckx] The idea is to create a new section that contains files like firmware images and FPGA data that gets written to the hardware to make it fully functional. It is not meant for drivers that run on the host CPU. Without weighing in on whether there _is_ a class of software for which users shouldn't have the right to look at and modify source code, this whole phrase run on the host CPU needs to die and be replaced by something more precise. Note that the draft text doesn't actually say that part. I only added it there to try and make it more clear. I'm not sure if the rest is open for many different interpretations. And I'm always open for better ways to describe it. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
On Tue, Dec 23, 2008 at 10:15:15PM -0800, Steve Langasek wrote: While I think it would be reasonable to include sourceless firmware on our CDs and DVDs, I don't think this is actually a very good solution to the problem we face: - if they're included on the official Debian images, they need to meet Debian's definition of free. The point of the proposal it to change things so that can be on the official images. - if the firmware are considered free, then they can live in main. Right, it's only for things we consider non-free. I would even expect some firmware to stay in non-free. - if the images the firmware is included on aren't Debian images, then there will (presumably) still be demand for pure Debian images, and we don't need to add a new archive section in order to include non-Debian stuff on the images Do you think there will still be a demand for them if d-i asks about using that new section? Having two sets of images doesn't make sense to me; the CD team have already posted publically this cycle about the infrastructure challenges involved with publishing those images that they already have to accomodate, doubling the image count doesn't sound feasible, IMHO. Doubling the image count seems to be the only way to do it now, and that's what I want to avoid. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
On Wed, Dec 24, 2008 at 12:16:47PM +0100, Kurt Roeckx wrote: On Tue, Dec 23, 2008 at 07:02:27PM -0600, Peter Samuelson wrote: [Kurt Roeckx] The idea is to create a new section that contains files like firmware images and FPGA data that gets written to the hardware to make it fully functional. It is not meant for drivers that run on the host CPU. Without weighing in on whether there _is_ a class of software for which users shouldn't have the right to look at and modify source code, this whole phrase run on the host CPU needs to die and be replaced by something more precise. Note that the draft text doesn't actually say that part. I only added it there to try and make it more clear. I'm not sure if the rest is open for many different interpretations. And I'm always open for better ways to describe it. What do you think about: We'll create a new area in our archive that contains files that must be sent to the hardware device so that functionaly becomes available to the DFSG-free driver. Kurt -- 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 Elections 2009: Call for nominations
On Mon, Mar 02, 2009 at 08:55:55AM +0100, Stefano Zacchiroli wrote: I hereby nominate myself for the forthcoming DPL elections. Your nomination has been received and is valid. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian Project Leader Election 2009: Final call for nominations.
On Sat, Mar 07, 2009 at 12:53:10AM +, Per Andersson wrote: On Fri, Mar 6, 2009 at 5:46 PM, Debian Project Secretary secret...@debian.org wrote: To be valid, a Debian Developer needs to send a signed email in which he nominates himself to the debian-vote@lists.debian.org list. Can't women nominate themselves? Of course they can. I will be more careful next time, and replace it by the candidate. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian Project Leader Election 2009: Final call for nominations.
On Sat, Mar 07, 2009 at 02:18:03PM +0100, Wouter Verhelst wrote: On Sat, Mar 07, 2009 at 12:11:16PM +0100, Kurt Roeckx wrote: On Sat, Mar 07, 2009 at 12:53:10AM +, Per Andersson wrote: On Fri, Mar 6, 2009 at 5:46 PM, Debian Project Secretary secret...@debian.org wrote: To be valid, a Debian Developer needs to send a signed email in which he nominates himself to the debian-vote@lists.debian.org list. Can't women nominate themselves? Of course they can. I will be more careful next time, and replace it by the candidate. (suggested phrasing: To be valid, a Debian Developers can send a signed email in which they nominate themselves, to the debian-vote@lists.debian.org lists I only noticed the he, but himself is of course also a problem. Thank you for the suggestion. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian Project Leader Election 2009: Final call for nominations.
On Sat, Mar 07, 2009 at 01:36:04PM +, Steve McIntyre wrote: On Fri, Mar 06, 2009 at 06:46:31PM +0100, Debian Project Secretary wrote: Hi, The nomination period for the DPL election is almost over. If you want to nominate yourself as canidate you need to send a signed mail to the debian-vote@lists.debian.org list. I hereby nominate myself as a candidate in the DPL election 2009. Platform to follow shortly. Your nomination has been received and is valid. Kurt -- 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
On Sun, Mar 08, 2009 at 01:19:27PM +0100, Kurt Roeckx - Debian Project Secretary wrote: Hi, The nomination period has ended and we're now in the campaigning period. We have 2 candidates: - Stefano Zacchiroli z...@debian.org - Steve McIntyre 93...@debian.org The page at http://www.debian.org/vote/2009/vote_001 has been updated. The platforms for these candidates shall be published as soon as they are available. I'm currently still waiting for them. Please send them as soon as possible. The platforms are now available at: http://www.debian.org/vote/2009/platforms/ Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Constitutional issues in the wake of Lenny
On Sat, Mar 14, 2009 at 12:07:03PM -0700, Russ Allbery wrote: Matthew Johnson mj...@debian.org writes: As Luk says, tackling these one at a time is probably best. So, first up is (bullets numbered so that I can refer to them): Positions (in no particular order): 1 The supermajority is rubbish and we should drop it entirely, so it doesn't matter what the difference is. 2 Anything which overrides a FD implicitly modifies it to contain that specific exception, even if it's not specified in the GR, so always needs 3:1. 3 Actually, the Social Contract isn't binding per-se, individual delegates/ developers are aiming for it as a goal, but can interpret it as they see fit. 4 The DFSG doesn't automatically trump our users, we'll cope with DFSG issues if it's needed for things to work. 5 Single exceptions don't require supermajority, but permanent changes do I'm not sure that I see my position in there, which is a combination of 2 and 3. The rule I would like to see is: 6 Anything which overrides a Foundation Document modifies it to contain that expecific exception and must say so in the proposal before the vote proceeds. Such overrides require a 3:1 majority. A GR which explicitly states that it does not override a Foundation Document but instead offers a project interpretation of that Foundation Document does not modify the document and therefore does not require a 3:1 majority. This is true even if the Secretary disagrees with the interpretation. However, such intepretations are not binding on the project. Would that be a position statement? That only seems to have a normal majority requirement. The problem I have with position statements is that they're not binding. But it atleast gives the secretary a consensus to base decisions on for other votes. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Constitutional issues in the wake of Lenny
On Sat, Mar 14, 2009 at 09:45:58PM -0700, Russ Allbery wrote: Kurt Roeckx k...@roeckx.be writes: On Sat, Mar 14, 2009 at 12:07:03PM -0700, Russ Allbery wrote: 6 Anything which overrides a Foundation Document modifies it to contain that expecific exception and must say so in the proposal before the vote proceeds. Such overrides require a 3:1 majority. A GR which explicitly states that it does not override a Foundation Document but instead offers a project interpretation of that Foundation Document does not modify the document and therefore does not require a 3:1 majority. This is true even if the Secretary disagrees with the interpretation. However, such intepretations are not binding on the project. Would that be a position statement? That only seems to have a normal majority requirement. The problem I have with position statements is that they're not binding. But it atleast gives the secretary a consensus to base decisions on for other votes. Yup, exactly, something that fit the last paragraph would be a position statement. I have no problem with considering the following to be position statements: - Firmware blobs are not a DFSG violation - Allow releases with known DFSG violations They are interpreting the DFSG/SC. But these do not seem like a position statement to me: - Allow Lenny to release with firmware blobs - Allow Lenny to release with known DFSG violations It does not say how to interprete the DFSG/SC, and both seem to temporary override the Foundation Document. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Constitutional issues in the wake of Lenny
On Mon, Mar 16, 2009 at 12:00:10PM -0700, Russ Allbery wrote: Kurt Roeckx k...@roeckx.be writes: But these do not seem like a position statement to me: - Allow Lenny to release with firmware blobs - Allow Lenny to release with known DFSG violations It does not say how to interprete the DFSG/SC, and both seem to temporary override the Foundation Document. Well, this is the reason why, in my proposal, I require that the GR explicitly say one way or the other whether it's overriding a FD if it's at all ambiguous. I don't believe either of those proposals should be allowed to go to vote until they explicitly say either that they're temporarily overriding a FD or that they believe that the release is consistent with the FD as written and are therefore a non-binding position statement on how the project interprets the FD. Basically, what I'm saying is that I'm not very worried about the case of a non-binding position statement saying that it doesn't override an FD but saying something completely contradictory to it. First, I don't think such a GR would pass, and second, even if it does, it's non-binding, so DDs who completely disagree with it aren't bound to follow it. If you have an option saying Allow Lenny to release with firmware blobs. This does not override the DFSG, I can only see that make sense if it really means: firmware blobs are not a DFSG violation, and the Lenny part doesn't make sense. The same goes for Allow Lenny to release with known DFSG violations. This does not override the SC. That would be the same as Allow releases with known DFSG violations. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Constitutional issues in the wake of Lenny
On Mon, Mar 16, 2009 at 08:13:05PM +0100, Wouter Verhelst wrote: On Mon, Mar 16, 2009 at 07:43:45PM +0100, Kurt Roeckx wrote: I have no problem with considering the following to be position statements: - Firmware blobs are not a DFSG violation - Allow releases with known DFSG violations They are interpreting the DFSG/SC. Actually, they are interpreting the DFSG, not the SC. That is about 2 different issues. The first is about firmware blobs. There are probably many different ways to look at this, and depending on what you say exactly you can get some firmware blobs to comply with the DFSG. The second is about releases and DFSG violations. The interpretation of the DFSG is not being questioned here. Just that we can make a release with DFSG violation or not. Note that there are more DFSG violations than just the firmware blobs. But these do not seem like a position statement to me: - Allow Lenny to release with firmware blobs - Allow Lenny to release with known DFSG violations It does not say how to interprete the DFSG/SC, It does. Those statements on themself do not. and both seem to temporary override the Foundation Document. No, they don't. For instance, Proposal B on the latest vote read, in full: | Allow Lenny to release with proprietary firmware | | 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. While it doesn't do so explicitly, the statement implicitly confirms that firmware blobs violate the DFSG; however, it explicitly states that dealing with this, while important, does not weigh up against the problems caused for our users by delaying the release. This is an interpretation of the SC, not the DFSG, and a perfectly valid position statement. That can be seen as an interpretation of SC #4 (our priorities are our users and free software). But I don't see it offer an interpretation for SC #1 (Debian will remain 100% free). Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Constitutional issues in the wake of Lenny
On Mon, Mar 16, 2009 at 11:52:33PM +0100, Wouter Verhelst wrote: The point is, language isn't math, and as a result the same text will often mean one thing to one person, and something entirely else to another. Which is my point. And people do have different opinions about it. So you now leave it up to the secretary to interprete it. It would be better if proposals would not leave a part open to interpretation. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
On Thu, Mar 19, 2009 at 12:50:45AM +0100, Bill Allombert wrote: Dear developers, I respectfully submit this general resolution proposal to your consideration. Please make clear what is part of the proposal and what is not. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposal: Enhance requirements for General resolutions
On Sat, Mar 21, 2009 at 03:47:57PM +0100, Joerg Jaspert wrote: PROPOSAL START General Resolutions are an important framework within the Debian Project. Yet, in a project the size of Debian, the current requirements to initiate one are too small. Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] (Numbers in brackets are references to sections in the constitution). PROPOSAL END It would be nice if this also included the proposed changes to the constitution as a diff. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposal: Enhance requirements for General resolutions
On Sun, Mar 22, 2009 at 01:39:13PM +0100, Andreas Metzler wrote: In article 87vdq3gcf6@vorlon.ganneff.de (gmane.linux.debian.devel.general) you wrote: [...] PROPOSAL START General Resolutions are an important framework within the Debian Project. Yet, in a project the size of Debian, the current requirements to initiate one are too small. Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] (Numbers in brackets are references to sections in the constitution). PROPOSAL END [...] seconded. gpg: Signature made Sun 22 Mar 2009 01:38:59 PM CET using DSA key ID 8B8D7663 gpg: BAD signature from Andreas Metzler (private key) ametz...@downhill.at.eu.org Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Amendment: Enhance requirements for General resolutions
On Sat, Mar 21, 2009 at 10:35:32PM -0300, Martín Ferrari wrote: On Sat, 2009-03-21 at 15:49 +0100, Joerg Jaspert wrote: PROPOSAL START General Resolutions are an important framework within the Debian Project. Yet, in a project the size of Debian, the current requirements to initiate one are too small. Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(Q). [see §4.2(1)] b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] (Numbers in brackets are references to sections in the constitution). PROPOSAL END I second this proposal This is the 5th second for this amendment. I currently count 3 and 1 failed second for the original proposal. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposal: Enhance requirements for General resolutions
On Sun, Mar 22, 2009 at 04:27:22PM +0100, Andreas Metzler wrote: [second try, this with mutt instead of tin] In article 87vdq3gcf6@vorlon.ganneff.de (gmane.linux.debian.devel.general) you wrote: [...] PROPOSAL START General Resolutions are an important framework within the Debian Project. Yet, in a project the size of Debian, the current requirements to initiate one are too small. Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] (Numbers in brackets are references to sections in the constitution). PROPOSAL END [...] seconded. This time it was good. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposal: Enhance requirements for General resolutions
On Sun, Mar 22, 2009 at 09:56:20PM +, Neil Williams wrote: PROPOSAL START General Resolutions are an important framework within the Debian Project. Yet, in a project the size of Debian, the current requirements to initiate one are too small. Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] (Numbers in brackets are references to sections in the constitution). PROPOSAL END Seconded That's the 5th second for that option too. Now two options have been accepted. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
On Mon, Mar 23, 2009 at 12:31:01PM -0700, Russ Allbery wrote: MJ Ray m...@phonecoop.coop writes: I hope that others will support this debian and co-op view. I continue to object to this GR as currently worded because it is a stealth delegate override that doesn't clearly state its implications and effects. I encourage all DDs to not second it until it's been fixed, even if you agree with the substance. The options I can see that might end up on the ballot would include: - 4.1.3: override a delegate [1:1] - 4.1.5: position statement about the AGFL [1:1] (Either the same as ftp-master, or the opposite.) - 4.1.5.3: override a foundation document [3:1] The last option is probably unlikely. The problem I see with a position statement is that it's non-binding and that the delegate's decission would still hold. What ftp-master does with that is up to them. I currently see no problem putting it under both of them, and would like to see that clearly in the text of the proposal. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposal: Enhance requirements for General resolutions
On Mon, Mar 23, 2009 at 11:51:37PM +, Steve McIntyre wrote: On Sat, Mar 21, 2009 at 03:47:57PM +0100, Joerg Jaspert wrote: PROPOSAL START General Resolutions are an important framework within the Debian Project. Yet, in a project the size of Debian, the current requirements to initiate one are too small. Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] (Numbers in brackets are references to sections in the constitution). PROPOSAL END Assuming that you'll provide explicit diffs for the constitution: Seconded. I'm not really sure how to interprete this. Does this mean you'll only second it after he changes the proposal to include the diff? Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Amendment] Reaffirm the GR process
On Tue, Mar 24, 2009 at 08:03:46PM +0100, Robert Millan wrote: I'd also like to complain about the title text of the initial GR. It is clearly manipulative, as it pretends to be merely describing the proposed changes when in fact it is asserting an opinion. I hope the Secretary will fix this. I think the title is also not the best one and just used Joerg's title. What about: General Resolution sponsorship requirements Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Amendment] Reaffirm current requirements for GR sponsoring
On Tue, Mar 24, 2009 at 04:49:54PM -0700, Lucas Nussbaum wrote: On 24/03/09 at 16:10 -0700, Lucas Nussbaum wrote: Hi, I am hereby proposing the amendment below to the general resolution entitled Enhance requirements for General resolutions. PROPOSAL START = General Resolutions are an important framework within the Debian Project. While over those years, some problems have arised during the discussion and/or voting of some resolutions, there is no evidence that changing the number of sponsors (seconds) for GR proposals or amendments will help solve those problems. Instead, by making it harder to propose general resolutions or amendments, it might make it harder to improve imperfect resolutions, or to add valuable options to a ballot. Therefore the Debian project reaffirms the current requirements for the sponsoring (seconding) of GR proposals or amendments, and for overruling of delegates. = PROPOSAL END Since nobody sponsored it yet, I'm amending it to fix: s/arised/arisen/ s/those years/the years/ The constitution even covers such changes: A.1.: 6. The proposer of a resolution may make changes to correct minor errors (for example, typographical errors or inconsistencies) or changes which do not alter the meaning, providing noone objects within 24 hours. In this case the minimum discussion period is not restarted. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Amendment] Reaffirm current requirements for GR sponsoring
On Wed, Mar 25, 2009 at 12:25:34PM +, Matthew Vernon wrote: Lucas Nussbaum lu...@lucas-nussbaum.net writes: Hi, I am hereby proposing the amendment below to the general resolution entitled Enhance requirements for General resolutions. PROPOSAL START = General Resolutions are an important framework within the Debian Project. While over those years, some problems have arised during the discussion and/or voting of some resolutions, there is no evidence that changing the number of sponsors (seconds) for GR proposals or amendments will help solve those problems. Instead, by making it harder to propose general resolutions or amendments, it might make it harder to improve imperfect resolutions, or to add valuable options to a ballot. Therefore the Debian project reaffirms the current requirements for the sponsoring (seconding) of GR proposals or amendments, and for overruling of delegates. = PROPOSAL END I second this. Please sign the message. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Seconding
On Wed, Mar 25, 2009 at 07:26:20PM +, Matthew Vernon wrote: Lucas Nussbaum lu...@lucas-nussbaum.net writes: Hi, I am hereby proposing the amendment below to the general resolution entitled Enhance requirements for General resolutions. PROPOSAL START = General Resolutions are an important framework within the Debian Project. While over those years, some problems have arised during the discussion and/or voting of some resolutions, there is no evidence that changing the number of sponsors (seconds) for GR proposals or amendments will help solve those problems. Instead, by making it harder to propose general resolutions or amendments, it might make it harder to improve imperfect resolutions, or to add valuable options to a ballot. Therefore the Debian project reaffirms the current requirements for the sponsoring (seconding) of GR proposals or amendments, and for overruling of delegates. = PROPOSAL END I second this. That's the 5th second. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Amendment] Reaffirm current requirements for GR sponsoring
On Thu, Mar 26, 2009 at 09:01:38AM +1000, Anthony Towns wrote: On Tue, Mar 24, 2009 at 04:10:49PM -0700, Lucas Nussbaum wrote: PROPOSAL START = General Resolutions are an important framework within the Debian Project. While over those years, some problems have arised during the discussion and/or voting of some resolutions, there is no evidence that changing the number of sponsors (seconds) for GR proposals or amendments will help solve those problems. Instead, by making it harder to propose general resolutions or amendments, it might make it harder to improve imperfect resolutions, or to add valuable options to a ballot. Therefore the Debian project reaffirms the current requirements for the sponsoring (seconding) of GR proposals or amendments, and for overruling of delegates. = PROPOSAL END Seconded. I realise there are already sufficient seconds to make this a valid option on the ballot, but it seems reasonable to see what it actually takes to get to the 15 or 30 or so seconds being proposed before voting. (From the vote.d.o page I gather there's currently 8 seconds for the proposal to require 2Q seconds, and 5 for Q seconds) It's now at: 2Q: 9 Q: 7 Keep current: 7 I've commited 9/7/5 a few hours ago, but there is a delay before the pages get regenerated. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Amendment] Reaffirm current requirements for GR sponsoring
On Thu, Mar 26, 2009 at 12:26:59AM +0100, Kurt Roeckx wrote: On Thu, Mar 26, 2009 at 09:01:38AM +1000, Anthony Towns wrote: On Tue, Mar 24, 2009 at 04:10:49PM -0700, Lucas Nussbaum wrote: PROPOSAL START = General Resolutions are an important framework within the Debian Project. While over those years, some problems have arised during the discussion and/or voting of some resolutions, there is no evidence that changing the number of sponsors (seconds) for GR proposals or amendments will help solve those problems. Instead, by making it harder to propose general resolutions or amendments, it might make it harder to improve imperfect resolutions, or to add valuable options to a ballot. Therefore the Debian project reaffirms the current requirements for the sponsoring (seconding) of GR proposals or amendments, and for overruling of delegates. = PROPOSAL END Seconded. I realise there are already sufficient seconds to make this a valid option on the ballot, but it seems reasonable to see what it actually takes to get to the 15 or 30 or so seconds being proposed before voting. (From the vote.d.o page I gather there's currently 8 seconds for the proposal to require 2Q seconds, and 5 for Q seconds) It's now at: 2Q: 9 Q: 7 Keep current: 7 To be complete, there is also: - Bill Allombert's simular proposal with 1 second. - MJ Ray's proposal about the expiry-on-failure with 1 second - Neil McGovern's s/K/Q/ with 1 second Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Amendment: automatic expiry-on-failure, to Proposal: Enhance requirements for General resolutions
On Thu, Mar 26, 2009 at 01:52:43PM +0100, Wouter Verhelst wrote: On Thu, Mar 26, 2009 at 08:43:16AM +, MJ Ray wrote: AMENDMENT START Replace too small with thought to be too small, but there is a lack of evidence about the correct level. Replace clause c with c) if a year has passed, starting from the proposal of a general resolution, without any proposal receiving the required number of seconds, then this resolution expires and the required number of seconds returns to K. AMENDMENT END Seconded. What exactly are you seconding? This is a proposal that modifies *3* of the other proposals. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Amendment] Reaffirm the GR process [rescinded]
On Thu, Mar 26, 2009 at 01:12:45AM +0100, Bill Allombert wrote: On Mon, Mar 23, 2009 at 11:42:40PM +0100, Bill Allombert wrote: Hello developers, I am hereby proposing the amendement below to the General resolution entitled Enhance requirements for General resolutions. PROPOSAL START General Resolutions are an important framework within the Debian Project, which have served us well since the first GR vote in 2003, with 804 developers, nearly has much as today slightly over 1000 developers. Therefore the Debian project reaffirms its attachement to the constitution and the current General Resolutions process. PROPOSAL END I am rescinding this amendment. Please second Lucas amendment instead, which has a cleaner wording. Robert, You're were the only one seconding that proposal, and now the proposer of this amendment. You might want to withdraw too and second Lucas's proposal instead. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
DPL 2009 election draft
Hi, This is a draft for the 2009 DPL election ballot. == Voting period starts 00:00:00 UTC on Sunday, March 29th, 2009 Votes must be received by 23:59:59 UTC on Saturday, April 11th, 2009 This vote is being conducted as required by the Debian Constitution. You may see the constitution at http://www.debian.org/devel/constitution. For voting questions contact secret...@debian.org. The details of the candidate platforms can be found at: http://www.debian.org/vote/2009/platforms/ HOW TO VOTE First, read the full text of the platforms and rebuttals. Do not erase anything between the lines below and do not change the choice names. In the brackets next to your preferred choice, place a 1. Place a 2 in the brackets next to your next choice. Continue till you reach your last choice. Do not enter a number smaller than 1 or larger than 3. You may skip numbers. You may rank options equally (as long as all choices X you make fall in the range 1 = X = 3). Please read the platforms in detail. To vote no, no matter what rank None Of The Above as more desirable than the unacceptable choices, or you may rank the None Of The Above choice, and leave choices you consider unacceptable blank. Unranked choices are considered equally the least desired choices, and ranked below all ranked choices. (Note: if the None Of The Above choice is unranked, then it is equal to all other unranked choices, if any -- no special consideration is given to the None Of The Above choice by the voting software). Then mail the ballot to: leader2...@vote.debian.org. Don't worry about spacing of the columns or any quote characters () that your reply inserts. NOTE: The vote must be GPG signed (or PGP signed) with your key that is in the Debian keyring. You may, if you wish, choose to send a signed, encrypted ballot. Devotee accepts mail that either contains only an unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail (RFC 3156 compliant). - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- a9ccc78e-785a-4762-a24a-ca59fe9b2dfe [ ] Choice 1: Stefano Zacchiroli [ ] Choice 2: Steve McIntyre [ ] Choice 3: None Of The Above - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- The responses to a valid vote shall be signed by the vote key created for this vote. The public key for the vote, signed by the Project secretary, is appended below. -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.9 (GNU/Linux) mQGiBEnNM0sRBACD6OeKJJPQQerENhPdQEO2pfDWyXxSUKOd0aA3u0aApAt7Pc9w v8c7d4cBprOj0M5Jj1bMlncSCYKluaD/izSbbUjXesrLhlhFfe+qxNk0BUupMXkl Zzj7M71X+x0gKKVCMqIHaFrfAwITYaINXfa1YYR/Ppy98cjGs3sKLsB6VwCgurx4 +vUhvxig27zVsbRYGmr5EJED/A4JhYLdfYj+E5hQcxs0g5HxwUVYfEEhoRS0ggh1 jy79SnFH7irxHpwFemH3ZkNPtltJj3QKTzhSsDWBeQIrM6ni8Q9R4+oFCwIhVpug wWkAi2wl4gbHnKPn1Dz72H24WLdheTZtzs30YkaBUgqQ/SnmPHzRerTDdA4dKvTz q1VaA/wPDWsM90pcMgEFlyL8hCo93R5mfEpPQx3PXn3bkiP8Moz3RIAjY14KwETI urupOiUnQfL6jjebow3wyRmexmb7Wjw9R+iVxePVTL+lRUxK3baNuO9o4t0SuFP9 GTNxQndKyzwqdRCqUJHEJTXaEA5vII3zBpB+Dc0AwOZy9xCGfrQqRFBMIFZvdGUg MjAwOSA8bGVhZGVyMjAwOUB2b3RlLmRlYmlhbi5vcmc+iGYEExECACYFAknNM0sC GwMFCQAXuwAGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRBWJrUvkcuEqF/wAJ0a yAYppfddTTTjKNnuxLbbsdYtqQCgouksCxMDOgWJ62t3DJh6AkwZbQuIRgQTEQIA BgUCSc06egAKCRBB3ByQckSXC6CvAKDaNn4nS6bXPNHd54ghw14HFSyV4ACffEGD ET/Vuvc0WH63juiqb73mpVS5Ag0ESc0zSxAIAN5//g8j1sEvNz/7/0Nopi+r3HZY sRo58ewVbsnUqb6Bs1Pi3Vo/3zjliiXR3ymJzNV6sNlNwBbaYgk3AIlsTvtKqWuF UZbyTLPfDvB5OklQ699cY3gYXqalTEDo8HE2JO9Pidpw1bjzQzbFuVjHAIfrK0zu tdsWge1UnObR9venMijCTsvyoPU57c5WSP/0lzK7QmsvFtkmFCk4MbcRqumjnfXW AbSTwn8vI2Ze7DISv9KzMJWSjw9SJl4KPT9MlC9Ag3MRypsGrRyfrS6CRHf2vTlO Fjr5obeZKP6RWimJJN7eTr0j+SQnMOkxvViDOcD6z+Jf0FfPg0pCgkTm+osAAwUH /3+6UyV5bmjnno4JigM5cZ20n4vjpTTpkBAGyyApfBCVxuTJDGbYl0TRxvdmsWYV dp/ZyHsyQk3c5jNq7Il8QSCfhuRSn5trizXf1OyudS+j5UT7kj6Ad3qF6TpLvbkw Zxy4e3g0TqPWWW1G8zah/vaXt90Zx3Y9F4lpbw2vMziFN7y1mXLs0YtYGHY2sLBd Hjq1PXeG6ifzoXkSvA22f8bWQS3oqKhTZYGht7q/aE9Isk781hEJvhjV/SrM0VGh y/n/23aDdruvkv4thb4f3LQhxtAKLJ3DSIf8fGjRzfIfX9jnMhjJSPdoSpLtWScW zzS5Hj74RTRBLzFakOrasluITwQYEQIADwUCSc0zSwIbDAUJABe7AAAKCRBWJrUv kcuEqFYIAKCtVUpHkkHEm3XWnvKooxY4yzJ3DgCghtOdEUkPVR0YS02o+9Ptmact Lxs= =CFD2 -END PGP PUBLIC KEY BLOCK- -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
On Mon, Apr 06, 2009 at 06:49:57AM +0300, Aigars Mahinovs wrote: 2009/3/19 Bill Allombert bill.allomb...@math.u-bordeaux1.fr: Dear developers, I respectfully submit this general resolution proposal to your consideration. Asking for seconds. - - - - - - - General Resolution made in accordance with Debian Constitution 4.1.5: The Debian project resolves that softwares licensed under the GNU Affero Public License are not free according to the Debian Free Software Guideline. - - - - - - - I second the above proposal. gpg: BAD signature from Aigars Mahinovs aigar...@debian.org Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Amendment] Reaffirm current requirements for GR sponsoring
On Thu, Apr 09, 2009 at 04:09:43PM +1000, Anthony Towns wrote: On Thu, Mar 26, 2009 at 09:01:38AM +1000, Anthony Towns wrote: On Tue, Mar 24, 2009 at 04:10:49PM -0700, Lucas Nussbaum wrote: General Resolutions are an important framework within the Debian Project. [...] I realise there are already sufficient seconds to make this a valid option on the ballot, but it seems reasonable to see what it actually takes to get to the 15 or 30 or so seconds being proposed before voting. (From the vote.d.o page I gather there's currently 8 seconds for the proposal to require 2Q seconds, and 5 for Q seconds) So according to the vote.d.o page, the minimum discussion period's done and a vote could be called for anytime... But there seems to only be 9 seconds for the proposals to require Q/2Q seconds, which is presumably 6 or 21 less than would indicate they're actually feasible... I think they would actually be 6 / 22 short. Q being 15.91 makes 2Q 31.82. So floor(Q) is 15, floor(2Q) is 31. Don suggested wording to change it to 2*floor(Q), but I think nobody commented on that. I'm not sure if someone who seconded one of the first two options would like to call for vote because they didn't reach number of seconds they would like to see. I can only suggest them to try and get more seconds. And I see no reason why someone who seconded the 3rd option would need to call for vote. Anyway, there is also this section in the constitution: A.5. Expiry If a proposed resolution has not been discussed, amended, voted on or otherwise dealt with for 4 weeks the secretary may issue a statement that the issue is being withdrawn. If none of the sponsors of any of the proposals object within a week, the issue is withdrawn. I'm just not sure when that 4 weeks start. The discussion period is now over, so I could do it 4 weeks from now. I could also interprete it to start from the last discussion on the list which seems to be March 27. Kurt -- 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 Results
On Mon, Apr 13, 2009 at 01:01:38AM +0200, Luigi Gangitano wrote: Hi Kurt, can you please report on issue in the voting software that prevented some ballots to be processed? I sent my vote twince on April 9 and April 11 and got the following answer back: Hi Luigi, I wish you contacted me about this before so that we could find a solution to get your vote counted. Looking at the mail that was received, I can properly verify your mail using mutt. It seems that devotee does not properly handle it. It seems to have to same effect as not undoing the quoted-printable encoding. I will atleast contact devotee's author to see if we can atleast fix this for future votes. He will probably want to see a signed message by your mail program. Since this is a secret vote, I think it's best to just send a new signed message. Kurt -- 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 Results
On Mon, Apr 13, 2009 at 11:46:54AM +0200, Luigi Gangitano wrote: Il giorno 13/apr/09, alle ore 01:43, Kurt Roeckx ha scritto: I wish you contacted me about this before so that we could find a solution to get your vote counted. Thanks for your report. I did not contact you before, since I oversaw the warning in the first vote report and dismissed it as a temporary issue in the voting software. I really don't mind my vote not being counted this time, it will not affect my future votes. :-) I was only trying to figure out if it was a common problem for this vote, and thus other votes where rejected, or was just my fault. I will atleast contact devotee's author to see if we can atleast fix this for future votes. He will probably want to see a signed message by your mail program. Since this is a secret vote, I think it's best to just send a new signed message. If Manoj wants to look at my ballot you can forward my message to him. There is nothing secret in my choice for 2009 DPL. I think he understands what the problem is. And the ballot stated what the mail needs to comply with. I will atleast make sure that the warning about the permissions will go away the next vote. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Devotee Improvements (Re: Debian Project Leader Election 2009 Results)
On Mon, Apr 13, 2009 at 01:23:56PM +0300, Kalle Kivimaa wrote: Would it be possible to add a pointer to the frequently encountered problems to the devotee error reply? This would most likely reduce the burden on the secretary during the voting period and allow people to solve the problems at their end faster. I was thinking of setting up a FAQ. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Devotee Improvements (Re: Debian Project Leader Election 2009 Results)
On Tue, Apr 14, 2009 at 10:48:12AM +0200, Stefano Zacchiroli wrote: On Mon, Apr 13, 2009 at 12:29:22PM +0200, Kurt Roeckx wrote: I was thinking of setting up a FAQ. .oO( Why not a Debian package?, then you would gain BTS support, and maybe people can help with software maintenance more easily ... ) See Manoj's mail about the package. The version being used can be checked by any DD. It's on master in the /org/vote.debian.org/bin/ dir. I'm more talking about having a page on www.debian.org that has things like common errors in it. And something that better explains how our voting system works. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Supermajority first?
On Fri, May 01, 2009 at 03:52:47PM +0200, Luk Claes wrote: Charles Plessy wrote: There were discussions started on the supermajority requirement, that unfortunately were unconclusive (20090302002303.gm29...@matthew.ath.cx), http://lists.debian.org/debian-vote/2009/03/msg3.html Nevertheless, wouldn't it be safer to first resolve this issue, while keeping as a goal to address the firmware question early in the release cycle? Well sponsors of the proposals have till Sunday to get it to vote AFAICS. Personally I would not mind to have a vote for this first and I won't start the process for a firmware vote before the vote about supermajority is either dropped (when no sponsor reacts) or voted on... Current vote that is in the process of being withdrawn has nothing to do with the supermajority requirement. It's about sponsorship requirements. The supermajority is about things like who decideds if something needs 3:1 supermajority if it's not clear. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Supermajority first?
On Fri, May 01, 2009 at 06:43:56PM +0200, Stefano Zacchiroli wrote: For instance, it would be very useful to know whether the current secretary would consider Peter's proposal on firmware to require super majority or not. If the secretary does _not_ think it will imply supermajority, it would be pointless to delay the vote on the basis of that. So, Kurt, what's your take on it? So, the problematic parts are: 1. firmware in Debian does not have to come with source. 2. we however do require all other freedoms that the DFSG mandate from components of our operating system If you only look at the first, you could interprete it as a position statement, but even then it's not clear that it's a position statement or not. But 2) makes it totaly unclear what 1) really means. 2) seems to indicate that 1) modifies some foundation document. So my problem with it is that it's too much open for interpretation. If you would like that such an option does not get a 3:1 majority requirement, I suggest you reword it so that it's clearly a position statement. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Draft GR: Simplification of license and copyright requirements for the Debian packages.
Please sign your message if you want to propose a GR. Kurt -- 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 Elections 2010: Call for nominations
On Fri, Mar 05, 2010 at 02:38:25PM +0100, Stefano Zacchiroli wrote: On Thu, Mar 04, 2010 at 10:42:29PM +0100, Debian Project Secretary - Kurt Roeckx wrote: I hereby nominate myself for the forthcoming DPL elections. Platform will follow according to the schedule suggested by Kurt. Your nomination has been received and is valid. Kurt signature.asc Description: Digital signature
Re: DPL Elections 2010: Last call for nominations
On Thu, Mar 11, 2010 at 11:02:28AM +0900, Charles Plessy wrote: I will run as well. Your nomination has been received and is valid. Kurt -- 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/20100311173929.gb28...@roeckx.be
Re: Nomination for DPL
On Thu, Mar 11, 2010 at 02:05:03PM -0300, Margarita Manterola wrote: I've been thinking a lot about this, and I consider that I could try to improve Debian from the role of DPL. I hereby nominate myself for DPL. I can only find the key CB27020A4D0F68ED63CFF1CC940B94C75B48FFAE for you in ldap. Kurt -- 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/20100311174210.gc28...@roeckx.be
Re: Nomination for DPL
On Thu, Mar 11, 2010 at 02:30:31PM -0300, Margarita Manterola wrote: I hereby nominate myself for DPL. Your nomination has been received and is valid. Kurt signature.asc Description: Digital signature
Re: Debian Project Leader Elections 2010: Candidates
On Tue, Mar 16, 2010 at 08:58:35PM +0100, Kurt Roeckx - Debian Project Secretary wrote: Hi, We're now a few days into the campaigning period. The candidates are: - Stefano Zacchiroli - Wouter Verhelst - Charles Plessy - Margarita Manterola The page at http://www.debian.org/vote/2010/vote_001 have been updated. The platforms for the candidates are now also available. So it seems not all mirrors have the pages yet. It might take some time before you can see them. Kurt -- 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/20100316211618.ga5...@roeckx.be
Getting more people involved in core teams.
I think that one of issues we have is that there is alot of work to be done by some teams, some of them even regularaly mail that they need more members, but they seem to have a hard time keeping the numbers up, burning the other team members out. What are your ideas to make sure those teams keep running? Kurt -- 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/20100323222539.ga8...@roeckx.be
Rebuttals.
Hi, All the rebuttals have been added to the platforms now, but they're not yet available on all the mirrors. Kurt -- 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/20100326000939.ga31...@roeckx.be
DPL2010 results
The unofficial results are at: http://master.debian.org/~secretary/leader2010/ The winner is Stefano Zacchiroli. There were some problems with the automaticly generated mail that should have been send to the list. You'll also notice that the graph has some issues. I will look at fixing this tomorrow and make the official announcement. Kurt -- 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/20100416000931.ga4...@roeckx.be
Re: GR: welcome non-packaging contributors as Debian project members
On Tue, Sep 14, 2010 at 01:04:32PM +0200, Gerfried Fuchs wrote: Wholeheartly seconed, for all the longstanding website translators. This isn't signed with a key in the keyring. Kurt -- 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/20100914185720.ga27...@roeckx.be
Re: GR: welcome non-packaging contributors as Debian project members
On Tue, Sep 14, 2010 at 07:42:58PM +0200, Damien Raude-Morvan wrote: I second this proposal. This message was signed with a key not in the keyring. Kurt -- 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/20100914191733.gb27...@roeckx.be
Re: Naming of non-uploading DDs (Was: GR: welcome non-packaging contributors as Debian project members)
On Wed, Sep 15, 2010 at 09:00:32PM +0900, Stefano Zacchiroli wrote: On Wed, Sep 15, 2010 at 09:26:59AM +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. ... and who am I to disagree with a proposal which find consensus from Lucas to Ganneff, passing through Lars and Russ? :-) Attached you can find a tentative wording of a proposal which remove the term Debian Contributors, pretty similar to the version I had before posting (shame on me for changing that!), but maybe a bit better in that it doesn't the horrible non-uploading Debian Developer. How about it? I don't consider this as something that changes the meaning of the original GR text. I'll let the patch linger for a couple of days -- actually, I'll be away for most part of tomorrow -- and then I'll apply it, posting a new complete draft here shortly thereafter. So I'm not considering this currently as an amendment. Kurt -- 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/20100915194009.ga14...@roeckx.be
Re: Naming of non-uploading DDs (Was: GR: welcome non-packaging contributors as Debian project members)
On Wed, Sep 15, 2010 at 02:13:12PM +0200, Simon Richter wrote: Hi, On Wed, Sep 15, 2010 at 09:00:32PM +0900, Stefano Zacchiroli wrote: The Debian project aims at producing the best free operating system. To that end the project benefits from various types of contributions, including but not limited to: package maintenance, translations, infrastructure and website maintenance, porting, bug triaging and fixing, management activities, communication, testing, legal advice, quality assurance, etc. The Debian project acknowledges that: * To pursue Debian goals, package maintenance as well as a wide range of other technical and non-technical contributions are all valuable. * Active contributors of non-packaging work, which share Debian values and are ready to uphold Debian Foundation Documents, deserve the opportunity to become Debian Developers. The Debian project therefore invites the Debian Account Managers to: * Endorse the idea that contributors of non-packaging work might become Debian Developers, albeit without upload access to the Debian archive. * Establish procedures to evaluate and accept contributors of non-packaging work as Debian Developers. * Initiate the appropriate technical measures to enable contributors of non-packaging work, which get accepted as Debian Developers, to participate in Debian decision making and to access Debian infrastructure. I like that a lot more than the other wording, thus seconded. Please don't go and make this more confusing for me. As far as I can tell this wasn't meant to be amendment yet. He will probably accept this or something simular as amendment replacing the orignal text. So at that time I could put you down as someone that seconds that proposal. You now basicly seem to have created a second proposal. Kurt -- 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/20100915194802.gb14...@roeckx.be
Re: Naming of non-uploading DDs (Was: GR: welcome non-packaging contributors as Debian project members)
On Thu, Sep 16, 2010 at 04:08:50PM +0900, Stefano Zacchiroli wrote: On Wed, Sep 15, 2010 at 09:40:09PM +0200, Kurt Roeckx wrote: I'll let the patch linger for a couple of days -- actually, I'll be away for most part of tomorrow -- and then I'll apply it, posting a new complete draft here shortly thereafter. So I'm not considering this currently as an amendment. Kurt, my inclination was to consider this change as falling under Constitution §A.1.3 as a change that does not alter the meaning of the proposal. That would be A.1.6? Do you disagree with that interpretation? If so I can, as the proposer, turn that change into a formal amendment and directly accept it (under §A.1.1 and §A.1.2), offering then the opportunity to seconders to disagree forking the text. I think it's in the best interest of all of us not to fork two options for *this* specific reason and I think §A.1.3 applies and it's the best way forward. My question was basicly if you wanted to make that change at that time. My interpretation is that you didn't propose to change it at that time, but that you would do it at some later time. The question was which part of the constituion this would follow. I also want to avoid having to fork it. Kurt -- 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/20100916164218.ga21...@roeckx.be
Re: Naming of non-uploading DDs (Was: GR: welcome non-packaging contributors as Debian project members)
On Thu, Sep 16, 2010 at 10:45:52AM +0200, Simon Richter wrote: Hi, On Wed, Sep 15, 2010 at 09:48:02PM +0200, Kurt Roeckx wrote: I like that a lot more than the other wording, thus seconded. Please don't go and make this more confusing for me. As far as I can tell this wasn't meant to be amendment yet. He will probably accept this or something simular as amendment replacing the orignal text. So at that time I could put you down as someone that seconds that proposal. You now basicly seem to have created a second proposal. I'm not sure I can create a proposal without actually saying so. So no, not yet. :) Basically, there are now two versions of the text floating around, where only one has been proposed as a GR, and where the original proposer (Stefano) has the option to adopt the changes, and thus turn the second version into his proposal, dropping the first. In case these changes are regarded as more than editorial (which is your call, but I feel they are), the new proposal requires new seconds I'm not sure why you think the proposal requires seconds if it replaces an older proposal. As long as nobody objects it doesn't need seconds. Atleast that's my current interpretation, feel free to try and convince me otherwise. Kurt -- 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/20100916165202.ga21...@roeckx.be
Re: Naming of non-uploading DDs (Was: GR: welcome non-packaging contributors as Debian project members)
On Sat, Sep 18, 2010 at 11:40:07AM +0200, Stefano Zacchiroli wrote: My question was basicly if you wanted to make that change at that time. My interpretation is that you didn't propose to change it at that time, but that you would do it at some later time. The question was which part of the constituion this would follow. That should be was not which. Kurt -- 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/20100918100730.ga6...@roeckx.be
Upcoming DPL election
Hi, We'll need to elect a DPL soon. The current plan for the timeline is: Nomination: Saturday March 5, 00:00 - Friday March 11, 23:59 Campaigning: Saturday March 12, 00:00 - Friday April 1, 23:59 Voting: Saturday April 2, 00:00 - Friday April 15, 23:59 Kurt -- 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/20110223202521.ga11...@roeckx.be
Re: Debian Project Leader Elections 2011: Call for nominations
On Sun, Mar 06, 2011 at 04:29:41PM +0100, Stefano Zacchiroli wrote: I hereby nominate myself for the forthcoming DPL elections. Your nomination has been received and is valid. Kurt signature.asc Description: Digital signature
Re: DPL elections 2011: Candidates
On Sat, Mar 12, 2011 at 11:47:30AM +0100, Kurt Roeckx - Debian Project Secretary wrote: The platform will be made available when it's ready at: http://www.debian.org/vote/2011/vote_001 I expect it to be there on monday. It's available now, atleast on the mirror I used. Kurt -- 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/20110314234614.ga13...@roeckx.be
Re: Debian Project Leader Elections 2012: Call for nominations
On Mon, Mar 05, 2012 at 10:30:04AM +0100, Wouter Verhelst wrote: So, it's that time again. On Fri, Mar 02, 2012 at 10:33:55PM +0100, Debian Project Secretary - Kurt Roeckx wrote: [request for nominations] I hereby nominate myself as a prospective DPL. Your nomination has been received and is valid. Kurt signature.asc Description: Digital signature
Re: Debian Project Leader Elections 2012: Call for nominations
On Mon, Mar 05, 2012 at 09:17:42PM +0100, Gergely Nagy wrote: I hereby nominate myself as a prospective DPL. Your nomination has been received and is valid. Kurt -- 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/20120305211847.gb22...@roeckx.be
Re: Debian Project Leader Elections 2012: Call for nominations
On Thu, Mar 08, 2012 at 11:26:55AM +0100, Stefano Zacchiroli wrote: On Fri, Mar 02, 2012 at 10:33:55PM +0100, Debian Project Secretary - Kurt Roeckx wrote: Please make sure that nominations are sent to (or cc:'d to) debian-vote, and are cryptographically signed. I hereby nominate myself as a prospective DPL. Your nomination has been received and is valid. ( just to give you all the once-in-a-lifetime opportunity to disprove the Italian proverb http://it.wikipedia.org/wiki/Non_c'%C3%A8_due_senza_tre ) Pointing to an Italian page really doesn't help for most of us. I understand it means Never two without three. Kurt signature.asc Description: Digital signature
Gergely Nagy: Disappearing?
Hi, As your platfrom indicates, you have disappeared from the Debian project before. Some DPLs started with alot of energy, but somewhat faded during their term and then disappeared. Do you think there is a chance of this happening to you? Kurt PS: I commited the platform some time ago, it takes some time before the webpages are re-generated and mirrored. -- 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/20120311015134.ga24...@roeckx.be
Debian Project Leader Elections 2012: Call for votes
Hi, This is the first call for votes for the Debian Project Leader Elections 2012. Voting period starts 00:00:00 UTC on Sunday, April 1st, 2012 Votes must be received by 23:59:59 UTC on Saturday, April 14th, 2012 This vote is being conducted as required by the Debian Constitution. You may see the constitution at http://www.debian.org/devel/constitution. For voting questions or problems contact secret...@debian.org. The details of the candidate platform can be found at: http://www.debian.org/vote/2012/platforms/ Also, note that you can get a fresh ballot any time before the end of the vote by sending a signed mail to bal...@vote.debian.org with the subject leader2012. HOW TO VOTE First, read the full text of the platform. To cast a vote, it is necessary to send this ballot filled out to a dedicated e-mail address, in a signed message, as described below. The dedicated email address this ballot should be sent to is: leader2...@vote.debian.org The form you need to fill out is contained at the bottom of this message, marked with two lines containing the characters '-=-=-=-=-=-'. Do not erase anything between those lines, and do not change the choice names. There are 4 choices in the form, which you may rank with numbers between 1 and 4. In the brackets next to your preferred choice, place a 1. Place a 2 in the brackets next to your next choice. Continue until you reach your last choice. Do not enter a number smaller than 1 or larger than 4. You may skip numbers, leave some choices unranked, and rank options equally. Unranked choices are considered equally the least desired choices, and ranked below all ranked choices. To vote no, no matter what, rank None Of The Above as more desirable than the unacceptable choices, or you may rank the None Of The Above choice and leave choices you consider unacceptable blank. (Note: if the None Of The Above choice is unranked, then it is equal to all other unranked choices, if any -- no special consideration is given to the None Of The Above choice by the voting software). Finally, mail the filled out ballot to: leader2...@vote.debian.org. Don't worry about spacing of the columns or any quote characters () that your reply inserts. NOTE: The vote must be GPG signed (or PGP signed) with your key that is in the Debian keyring. You may, if you wish, choose to send a signed, encrypted ballot: use the vote key appended below for encryption. The voting software (Devotee) accepts mail that either contains only an unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail (RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME. - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- da569edd-e41f-4ecd-b0d5-ce2848a777f9 [ ] Choice 1: Wouter Verhelst [ ] Choice 2: Gergely Nagy [ ] Choice 3: Stefano Zacchiroli [ ] Choice 4: None Of The Above - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- ponses to a valid vote shall be signed by the vote key created for this vote. The public key for the vote, signed by the Project secretary, is appended below. -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.12 (GNU/Linux) mQINBE93XhgBEAChIKhRwi7drrN36XqVesKmqW4UoKGeacS/6HBbZPHfm7Hw7gCm niomrpWcWOgrVLw+z+UTB9YGUSoiKF5yVZTcpQg+snaFAcWFgg4MOY1NrAGTdA95 eNt6ZKwE9AajZVimmOEeG9bnYF3ZJuCvPAJFsm28mA42Fbzo6K+f/J51zJCKapA/ npjI4cAd2Gb6R9pbUS7OooBqYXlG5xe3p3TepyWLBKUMwrR0+q0yacs2ubVps0IS XgWySgZ/T7LB78NmqMGYN05bgOPL/y2n5Dq9h24TEKxT3i+0jxFKHnnEvEvbKZ4E ixxGs8U/D82NWTQLbXGjFpCZmIZj1v724SWRiCunqepGMS7SpIKSI8XFp37YJhU5 wWfMm6Pho6pXf3MdTV7x9bJPKgRr7UoKVRUl3AxHM5M+JDTbCva6l23ga7plxY+E vx9UMwj9TbJgprMAoLP59q2djkUOK6FM3x4Elj8SBsCHHFpg3rNuqUPxERszzIex 1/NxUQA8n/RuVuZ+sCL4PThR4g387SyRx+9cj7MHP+GAOrMpibY4qK92lXtetA09 YxbsIhBAESLRhbmMEQL6WzpxMmhynU2uk34dATBfocH425MDvWd5Qsqrsc/AIBla ziyHwl1KqmjBl25CzF+hM4gKtsaxg8paphKwiTP6a1D0FDqIaF1HJKCoiQARAQAB tCpEUEwgdm90ZSAyMDEyIDxsZWFkZXIyMDEyQHZvdGUuZGViaWFuLm9yZz6JAj4E EwECACgFAk93XhgCGwMFCQAaXgAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJ EJ0M4QzEI7mhVSAP/0p3k20icRBe4a9qpK6QrjzXpcOfi8fMzJukmzj3xflbOMw9 XMx6GCMQ9wBoRNxb07mlBCD7qaol5bMW3LyEB7NRxSK0Qil2615/N6cUa2Je1lgr xxX1HmE3PX0of2TDVaKatk0OxsA9zmWQ5n5+YBxuVS3dL2Ej7eNR28rJ4lkRPTiK 3C3AD1EQ15GD6Gg3jR1st0PsJif5JA3jkIV1HZo72HePgPsLGVtVJZ9EAlHku+cY 3doTpGVcKP2f6WfmD0ONalzaHTKvqAPb5N52gX4QTPC1HmDj/p36c7rbt8YRDbg7 5wD8HQxCn/vRQRQmQRvaZuBor/KVuTcqoAKesqeeDHZft13s1sGdIgNss26erzPy jSTdPw48g44ND3BJzwR92G4IWgrnZw/h4O8S17ZmUjCI8nqV4twS6IiSa8POddtf zjjSpl5YJRimaWtVt7ogABRDfgKZpCfPUn3vH1O05R7yuA6RWegx7chRmhSRSE8F C4slcmd3hQqzLpELVo/EnQMfao+0qpnRfirGmUwy4hZQGLWOfVuYDoE4v7C/zDQH /2TJVFDRPjGfT2HFu8tjzKoE7ASoUI1fjd4S3h+Ggd7/3YegMzzFzwx982UEDoDt YQTiSOM7Qt87qYk6SDRwZQVjL/N13rNLGYZ1g5/s8opi/5A68Pue9gZQuK6FiEYE ExEKAAYFAk93X9cACgkQQdwckHJElwsVOQCaAhCnPJUMows+HRM0QL+ONsuqV+IA n3o+LVuTENNqZDqDvIJJFjGo+0twuQINBE93XhgBEADKIk2dg81w+yaQDfJYgO+0
Re: [Draft] GR: diversity statement for the Debian Project
On Thu, May 03, 2012 at 12:32:03AM +0200, Francesca Ciceri wrote: Q: What will be the procedure for maintaining/updating the statement, once voted? A: The gist of the statement will be fixed by the GR. But in order to avoid needing a vote for every minor tweak, language improvements can be applied by the -www team as for other parts of www.d.o and more substantial changes, that do not change the spirit, can be discussed on -project. I'm not sure we want editorial changes. Kurt -- 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/20120503215432.ga14...@roeckx.be
Re: General Resolution: Diversity statement
On Wed, May 09, 2012 at 07:21:10AM +0900, Charles Plessy wrote: Hi all, I hope that our constitution has the answer to that question. If a GR needed self-locking dispositions, that would go against the idea of having a constitution at all. My personal opinion is that for things that should not be changed apart with a GR, the Constitution offers the status of Foundation Document. So if the diversity statement is not a foundation document, I do not see what would forbid to change it after the GR. Note that a foundation document requires a 3:1 majority to change it, while a posistion statement only requires a simple majority. Kurt -- 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/20120509170534.ga23...@roeckx.be
Re: [Call for seconds] GR: diversity statement for the Debian Project
On Thu, May 10, 2012 at 01:17:45AM +0200, Mònica Ramírez Arceda wrote: I think I'm late but... As long as nobody called for the vote, I don't see a problem adding more seconds. Kurt -- 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/20120510200341.ga17...@roeckx.be
Re: [Call for seconds] GR: diversity statement for the Debian Project
On Mon, May 07, 2012 at 08:32:41PM +0200, Francesca Ciceri wrote: TEXT TO BE VOTED STARTS HERE The Debian Project welcomes and encourages participation by everyone. No matter how you identify yourself or how others perceive you: we welcome you. We welcome contributions from everyone as long as they interact constructively with our community. While much of the work for our project is technical in nature, we value and encourage contributions from those with expertise in other areas, and welcome them into our community. TEXT TO BE VOTED ENDS HERE The one 1 week discussion period is now over. Kurt -- 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/20120514213310.ga1...@roeckx.be
Re: Call for vote - Diversity statement for the Debian Project
On Tue, May 15, 2012 at 11:34:42PM +0200, Francesca Ciceri wrote: Dear Debian Developers, since the minimum discussion period is now over and since no amendments have been proposed, I'm hereby calling for a vote. TEXT TO BE VOTED STARTS HERE The Debian Project welcomes and encourages participation by everyone. No matter how you identify yourself or how others perceive you: we welcome you. We welcome contributions from everyone as long as they interact constructively with our community. While much of the work for our project is technical in nature, we value and encourage contributions from those with expertise in other areas, and welcome them into our community. TEXT TO BE VOTED ENDS HERE-- A corresponding ballot might look like the following: --- [ ] Choice 1: Welcome everyone [ ] Choice 2: Further discussion --- I'll start the vote during the weekend. But I need to think about the name of the option, I wasn't very happy with it when I wrote that. Kurt -- 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/20120515222831.ga18...@roeckx.be
Re: Call for vote - Diversity statement for the Debian Project
On Thu, May 17, 2012 at 07:26:33PM +0200, Stéphane Glondu wrote: Le 16/05/2012 00:28, Kurt Roeckx a écrit : I'll start the vote during the weekend. But I need to think about the name of the option, I wasn't very happy with it when I wrote that. Has the issue mentioned in [1] been taken into account? [1] https://lists.debian.org/debian-devel/2012/04/msg00528.html That's not relevant since this is not a secret vote. Kurt -- 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/20120519005440.ga7...@roeckx.be
Re: (maybe) constitutional amendment: clarification of section 5.1.5
On Sat, May 19, 2012 at 04:57:56PM -0700, Steve Langasek wrote: Rejected amendments, i.e. those that result in additional ballot options, do not reset the discussion period. I think they do reset the discussion period when they get accepted (have enough seconds), but I would need to re-read that to confirm it. Kurt -- 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/20120520001749.ga29...@roeckx.be
Re: (maybe) constitutional amendment: clarification of section 5.1.5
On Sat, May 19, 2012 at 06:18:29PM -0700, Steve Langasek wrote: On Sun, May 20, 2012 at 02:17:49AM +0200, Kurt Roeckx wrote: On Sat, May 19, 2012 at 04:57:56PM -0700, Steve Langasek wrote: Rejected amendments, i.e. those that result in additional ballot options, do not reset the discussion period. I think they do reset the discussion period when they get accepted (have enough seconds), but I would need to re-read that to confirm it. Please re-read - this is not what accepted means in the context of an amendment :) After re-reading it, I have to agree. Kurt -- 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/20120520124020.ga5...@roeckx.be
Re: [all candidates] the release process
On Wed, Apr 03, 2013 at 06:36:14PM +0100, Jonathan Dowland wrote: On 3 Apr 2013, at 17:29, Moray Allan mo...@sermisy.org wrote: The campaign period already finished a few days ago Yes, I was aware of that when I posted, but RL interfered with me asking prior to voting opening. I sought advice as to whether it was appropriate to ask further Qs and got a luke-warm yes. My reading of the timescale did not proclude questions past the start of voting, it seems ambiguous. So as I understand it we candidates aren't meant to reply to election questions any more. If the candidates are reluctant to answer now for this reason perhaps the secretary or current dpl can clarify or rule on the issue? It was always my interpretation that discussion / campaigning period was meant to help voters to form an opinion, and that it stops after that period. I expect people who have already voted not to follow the discussions anymore, so it makes sense to me that during the voting period the candidates would stop replying to questions or making statements that could influence voters. Of course I don't expect them to be silent during the whole voting period, and I see no reason they can't participate in other discussions. I also see no reason why other people should stop discussing things that are important to the project. But the candidates should probably think twice before participating in such discussions during the voting period. Kurt -- 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/20130403204747.ga13...@roeckx.be
