Re: Re-Proposal - preserve freedom of choice of init systems
On 10/16/2014 11:07 PM, Kurt Roeckx wrote: Can I ask people to move discussion that is not relevant to the vote to some other place? Do you really think anyone will feel that their contribution was not relevant for the vote? Anyway, is someone willing to propose an option that would postpone preserving the freedom of choice of init systems till after the release? Kind regards Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544036c3.8050...@debian.org
Re: Wouter and Gergely: software monopoly vs diversity
On 03/17/2012 06:46 PM, Wouter Verhelst wrote: On Sat, Mar 17, 2012 at 09:01:55AM +0800, Paul Wise wrote: On Fri, Mar 16, 2012 at 9:57 PM, Wouter Verhelst wrote: In some cases, of course, that isn't the case, and then things get somewhat more complex. A good example on that is the systemd discussion on -devel currently: making systemd the default and required init implementation would, in the current state of things, instantly axe the kFreeBSD port. I am of the opinion that this simple fact therefore rules out systemd as the default and required init implementation for Debian; but it looks as if not everyone shares that opinion currently. I think you will find that debootstrap supports installing different packages on different architectures. Yes, but it's not about debootstrap. If an init system that is incompatible with our current default init system becomes the only supported init system, then architectures on which that init system doesn't work, suddenly have no working init anymore. having a choice of multiple init implementations is indeed a good way of fixing the issue, but that's not what some of the proponents of systemd seem to be arguing for, and it's not what's relevant for this particular question. AFAICS one is requesting to change the default to a dependency based boot system as the early boot gets less and less reliable (networking as the key example). The remaining issue seems to be choosing between upstart and systemd as default. Obviously making sure initscripts keep working will get harder and it's up to the ports that don't support the default init system to choose the lesser of two evils (porting the default init system or making sure initscripts keep working) IMHO. Opposing evolution because some architectures don't follow it, will probably only result in more tension. All ports have to evolve due to changed circumstances. It's only when they do not that the cry to not support them officially anymore gets louder and louder AFAICT. Cheers Luk -- 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/4f64d9a6.6020...@debian.org
Re: Draft GR: Simplification of license and copyright requirements for the Debian packages.
Charles Plessy wrote: Le Mon, Jan 25, 2010 at 12:42:07AM +, MJ Ray a écrit : Charles Plessy ple...@debian.org H Le Sun, Jan 24, 2010 at 10:56:36PM +, MJ Ray a écrit : Charles Plessy ple...@debian.org According to our social contract, “We promise that the Debian system and all its components will be free according to [the DFSG].” [...] Wow, that's a twist. So how do you get around the idea that the program must include source? in my opinion, if a file contained in a Debian source package has no function in the Debian system, if its removal has actually no effect on the system at all, then it is reasonable to declare that it is not part of the Debian system. In other words, just blatently ignore the bit of the DFSG that says that programs must include source. Well, that explains it :-/ Yes, exactly. In this draft GR I propose to ignore some DFSG-non-free files, which includes sourceless files. Our social contract only stipulates that the Debian sytstem must be DFSG-free. We already have a non-free section for the non-free works that we would like to distribute for the purpose of being used with the our operating system. I think that our social contract also allow us to distribute innert non-free files together with the source of the Debian system as long as they do not take part of it. And who in their right mind do you expect to vote for ignoring DFSG non-freeness, people that want to leave the project? The source is part of the Debian system as you call it, so what it contains should be DFSG free. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [OT] Re: Draft GR: Simplification of license and copyright requirements for the Debian packages.
Charles Plessy wrote: Le Mon, Jan 25, 2010 at 08:28:01AM +0100, Luk Claes a écrit : And who in their right mind do you expect to vote for ignoring DFSG non-freeness, people that want to leave the project? For the record, I will not answer in this thread to other posts that are insulting, question people's mental health, or suggest that people who disagree should leave. So why do you expect us to do that with your GR draft? Cheers Luk -- 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 (take 2)
Bill Allombert wrote: 13. Remote Network Interaction; Use with the GNU General Public License. Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph. This is obviously only relevant if the software is interacted with remotely which is made cristal clear with the '(if your version supports such interaction)'. 2. This clause is incompatible with Section 3. of the Debian Free Software Guideline: 2.1 This clause restricts how you can modify the software. Doing a simple modification to a AGPL-covered software might require you to write a substantial amount of extra code to comply with this clause. Not at all unless the modified version is interacted with remotely which should make providing the source trivial AFAICS? 2.2 This clause forces the developer modifying the software to incur cost. A developer modifying the software and distributing the modified version need to incur the cost of providing access to the Corresponding Source from a network server as long as at least one person is using the software and this for all published modifications, even long after the developer stopped using and/or distributing the software. As long as the users are using it by interacting remotely with it... 2.2. While this clause does restrict mere use of the software, instead it creates liabilities for people modifying the software, even if they distributed their modified version in source form, with respect to the way the software perform on user systems. If you distribute it in source form, there are no users interacting with it remotely AFAICS? -- Modifying the software can unwillingly introduce a bug that cause it not to comply with this clause. How so? -- A user of the modified version can mis-install it, mis-configure it or run it in an untested environment where it does not comply with this clause. Yes, that's the same for many other software where you for instance need to show a disclaimer. -- A user of the modified version can use it in a configuration that cause it to fail to comply with this clause (for example using a reverse proxy that remove link to the source code from the html output). Same as above. 3. This clause is incompatible with Section 6. of the Debian Free Software Guideline. 3.1 This clause does not allow you to modify the software to perform tasks where complying with it is not technically feasible, for example: -- The code is modified to run on an embedded system with tight size limit. And there will be users remotely interacting with it? While possible, it's something to consider when using it on an embedded device. Though the same is true for huge applications. -- The code is modified to interact with the user using a network connection with extremely low throughput. Why would that cause any problem? It's not because one needs to provide the source that it has to be downloaded AFAICS? -- The code is modified to interact with the user using a network protocol that does not allow to display a prominent offer. Any example of this? Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Draft vote on constitutional issues
Matthew Johnson wrote: On Sun May 10 18:34, Luk Claes wrote: 3. Option X overrides a foundation document, possibly temporarily (?) Not possible. You can only override a decision and amending a foundation document is the previous option. What would you call the vote to ship non-free software in etch? Because that is what I mean. We are agreeing to do something which the foundation document said we would not, but only for a certain period of time (etch). Well, that's rather incomplete as that means that we are shipping non-free software in main before etch (in experimental, unstable, testing), in stable (etch) and probably still after etch till it gets fixed in experimental, unstable, testing. As it is very strange formulated for what is really happening and it's ultimately the maintainer and ftp-master's decision to ship it like that, I don't see why you want to vote on it? It's not like you override the decision of the maintainer/ftp-master, but rather acknowledge it. I don't _care_ what you call that, I call it a temporary override of a foundation document. Please do read the constitution and don't use these terms if you mean something else. A temporary conflict with the foundation document for some packages is only as temporary as the issues getting fixed. I don't see why there needs to be a vote for a release as the release is only showing to the broad audience what was already there all the time and not getting fixed. When the Release Team decides to tag an issue release-ignore, it does that when there are clear signs that the issues are being worked on, but it being unrealistic to get fixed in time for the release. If it would get fixed in time, the Release Team would of course still try to include the fix in the release. You could of course argue that the maintainer and ftp-master were not respecting a foundation document, though in that case you should override their decision IMHO. 4. Option X is declared not to be in conflict with a foundation document (?) 5. Option X conflicts with a foundation document, but explicitly doesn't want to override the FD (?) 6. Option X would appear that it might contradict an FD, but doesn't say which of 2-5 it is. 4-6 are normal position statements AFAICS. That's certainly a point of view, but not the one every holds. Yes, though please give some clear indications in the constitution on how you can interpret it differently as I don't see them, TIA. 1. and 2. are what we wish every vote were like. 3. is things like we agree that the kernel modules aren't free, but we'll ship them anyway or we'll ship them for this release. This one would be in 4-6 AFAICS. Why do you say that. This is definitely contrary to a foundation document (if you don't think it is, please pick a different example which is) and we want it to be binding. Ergo, not a position statement. Well, there is no such category in the constitution. If you do want to include it, you'd better prepare a vote to include it IMHO. 5. is something like Allow Lenny to release with firmware blobs. This does not override the DFSG, which I don't think makes any sense. One cannot override a document. See above. I'm not interested in arguing about terminology, I think it's clear what I mean by 'override a document', please suggest alternative phrasing if you prefer. It's you who are using the terminology in a different context and meaning than what is used in the constitution AFAICS. As the DFSG is a document that state our guidelines of what is free, I don't see how it would get changed even temporary when we would have a vote on 'Allow Lenny to release with firmware blobs'. OK, if you prefer it changes the SC to allow exceptions which don't conform to the DFSG. I'm sorry if I'm not being clear here, I was hoping people would get the gist of what I meant, but I'll try and be more pedantic in future. Nope, it's telling that firmware blobs are not covered by the DFSG for Lenny. It can't both conflict and not be covered by the same document AFAICS? Now, I understand you don't like the use of 'override' when describing option 3, I'm happy to describe it as something else, but _I_ think that the constitution at the moment requires 3:1 majority for this sort of vote. I know other people are equally certain it does not, but this is why I want to clarify it one way or another, to avoid future upset. Well, what I propose to do is to read the constitution and use its terms instead, which would ease these discussions a lot AFAICS. That would be great, unfortunately there seems to be a bit of a grey area here, hence the problems. Only because people don't seem to read the constitution and follow some ideas from what's included in the constitution that I don't find written in it. Please do point me to the relevant sections of the constitution if you find them, TIA. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
Re: Draft vote on constitutional issues
Thomas Bushnell BSG wrote: On Tue, 2009-05-12 at 20:09 +0200, Luk Claes wrote: Either Social Contract section one and the DFSG prohibit the distribution of a non-free blob in the release, or they do not. This 'in the release' is bogus, I guess you mean in 'main'? Debian is only free software. Non-free is distributed by Debian, but it is not part of Debian. By in the release I mean the released versions of Debian (which includes only main and optional). We don't have a component called optional, nor do we only distribute our releases. If they prohibit it, then it is an override to distribute notwithstanding the prohibition. If they do not prohibit it, then no resolution is necessary. You seem to say an inconsistent thing: that they do prohibit it, and we can avoid that prohibition by calling it a practical consensus instead of an override. Surely, however, it is the effect that matters, and not the label you give it. Well that's the thing with goals, they are not strict rules, but we do try to reach them (though not at all cost) ... Perhaps you should propose an amendment to our Social Contract, which speaks not of goals and aims, but of promises. Indeed, the point behind the language of *contract* is that these are not merely goals, but firm promises. You presumably would support an amendment to section one of the social contract, changing it from a promise into a statement of a goal. But such an amendment has not yet been passed, and your clear declaration that you are not willing abide by the social contract as written is troubling. It's already included in there: Debian will remain 100% free. As we're only improving, I don't see how it's not a goal as we were never 100% free, we are not 100% free and probably will never be 100% free. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Draft vote on constitutional issues
Thomas Bushnell BSG wrote: On Tue, 2009-05-12 at 17:06 +0200, Wouter Verhelst wrote: I think this is the core of the disagreement. I do not call it a temporary override of a foundation document; I call it a temporary practical consensus between the needs of our users and the needs of the free software community. I don't understand. Either Social Contract section one and the DFSG prohibit the distribution of a non-free blob in the release, or they do not. This 'in the release' is bogus, I guess you mean in 'main'? If they prohibit it, then it is an override to distribute notwithstanding the prohibition. If they do not prohibit it, then no resolution is necessary. You seem to say an inconsistent thing: that they do prohibit it, and we can avoid that prohibition by calling it a practical consensus instead of an override. Surely, however, it is the effect that matters, and not the label you give it. Well that's the thing with goals, they are not strict rules, but we do try to reach them (though not at all cost) ... Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Draft vote on constitutional issues
Matthew Johnson wrote: On Sat May 02 00:32, Luk Claes wrote: PS: There is a reason why I send the mail about the definitions of the terms even if Kurt as well as you seem to ignore it. I posted a while back citing several types of vote option [0], with some examlpes. I'm maybe not using the terminology you'd like, but I hope you can see what I mean. Here they are again: 1. Option X conforms to a foundation document (clearly not 3:1) 2. Option X changes a foundation document (clearly 3:1) 3. Option X overrides a foundation document, possibly temporarily (?) Not possible. You can only override a decision and amending a foundation document is the previous option. 4. Option X is declared not to be in conflict with a foundation document (?) 5. Option X conflicts with a foundation document, but explicitly doesn't want to override the FD (?) 6. Option X would appear that it might contradict an FD, but doesn't say which of 2-5 it is. 4-6 are normal position statements AFAICS. 1. and 2. are what we wish every vote were like. 3. is things like we agree that the kernel modules aren't free, but we'll ship them anyway or we'll ship them for this release. This one would be in 4-6 AFAICS. 4. is things like we think that firmware can be its own source, so shipping blobs is fine 5. is something like Allow Lenny to release with firmware blobs. This does not override the DFSG, which I don't think makes any sense. One cannot override a document. As the DFSG is a document that state our guidelines of what is free, I don't see how it would get changed even temporary when we would have a vote on 'Allow Lenny to release with firmware blobs'. Now, I understand you don't like the use of 'override' when describing option 3, I'm happy to describe it as something else, but _I_ think that the constitution at the moment requires 3:1 majority for this sort of vote. I know other people are equally certain it does not, but this is why I want to clarify it one way or another, to avoid future upset. Well, what I propose to do is to read the constitution and use its terms instead, which would ease these discussions a lot AFAICS. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Overriding vs Amending vs Position statement
Matthew Johnson wrote: On Sat May 02 00:52, Luk Claes wrote: It would be a clear indication that the foundation document should get an update or that the postition statement should get dropped again. I think Manoj's point is that if voting some option X (a position statement in conflict with an FD) means that we have to vote to change the FD or drop X, then why wasn't X a vote to change the FD in the first place? Surely we don't need a vote just to then have another vote... Well, I think it's wrong to force the vote to be about changing the FD when the proposer and the seconders agreed that it should not. Note that you don't know if there would be another vote needed as one cannot know beforehand if the vote would pass or not. Note also that it might be easier to get a position statement than to find appropriate wording and support to change the FD. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Firmware
Hi As probably many of you know, the most heard criticism from users and press on Lenny's release is lost hardware support because of missing firmware. Users and press are complaining that their servers don't have network anymore after an upgrade or that their notebooks cannot be installed via wireless... It's of course possible to load firmware from extra media during installation or install the right package (from non-free) when booting back to an older kernel (to have network again) to be able to use the network with the new kernel... What do people think of a new vote regarding the status of firmware? One of the options can probably be Peter Palfrader's proposal [1]. Cheers Luk [1] http://www.debian.org/vote/2008/vote_003#textf -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Supermajority first?
Charles Plessy wrote: Le Fri, May 01, 2009 at 01:58:43PM +0200, Stefano Zacchiroli a écrit : I'm very much in favor of having this vote early in the release cycle, Hi all, 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... Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Supermajority first?
Kurt Roeckx wrote: 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. Ah right, too much things to vote on :-) Well, I think the sponsorships requirement vote that is currently being in process should first be dealt with (either dropped or voted on) first. Continuing discussions about the supermajority requirements before going to the firmware is probably not a bad idea. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Overriding vs Amending vs Position statement
Hi There seem to be some disagreements about the terms in the subject. As far as I'm concerned it's pretty clear though and would not need any vote to clarify: Overriding is only used in combination with decisions. You cannot override a document or its interpretation/meaning. You can only override a DD's (or delegate's) decision. Amending is changing something written like a foundation document or a proposal. As far as I can see you can only amend explicitly so there should be no confusion. A position statement is a decided on proposal that clarifies the position of the Debian project, but does not explicitly amend a foundation document. Supersession of a Foundation Document is replacing a Foundation Document with another version: introduce a new one, ammend one or remove one. According to the Debian Constitution there is only a 3:1 majority needed to ammend the Constitution or supersede a Foundation Document. So I don't really see what we should vote on unless someone disagrees with above interpretations? Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Overriding vs Amending vs Position statement
Matthew Johnson wrote: On Fri May 01 11:56, Don Armstrong wrote: So I don't really see what we should vote on unless someone disagrees with above interpretations? The only question resides with the effect of passing such position statements. Without modifying foundation documents or the constitution, they are effectively non-binding advisory statements when operating within areas that are the remit of foundation documents or the constitution. Indeed and there is the case of temporary exceptions. Does saying we will release with non-free stuff involve modifying a foundation document? I would say yes. Does saying we will release Lenny with non-free stuff involve modifying a foundation document? There seems to be less agreement on this. I think it does, but the previous discussion showed that some people disagree. This always sounds very awkward to me. So if we would just not fix bugs about non-free stuff everything is ok, but if we want to release it has either to be fixed very quickly or get a vote that modifies a foundation document? Sorry, but I did not and will not agree with that. We will not release with random non-free stuff, nor will we release with easily fixable non-free stuff, nor will we release with non-free stuff where it's clear that upstream does not care in fixing it. We will release with non-free stuff that does not get fixed in time where upsteam is working on it though. I don't see why this would need any vote, though if you really think it's useful to have a vote on this, so be it. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Supermajority first?
Kurt Roeckx wrote: 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. It appears you either don't agree with my other post or did not read it as there is no interpretation needed to see if something is a position statement. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Draft vote on constitutional issues
Matthew Johnson wrote: As suggested [0] I think we should clarify these issues before any other votes. As such I'd like to suggest a draft for the vote. I'm proposing several options for a couple of reasons. Several of them I would rank above further discussion, but I also want to make sure that there is an option for everyone on here. I'm trying to clarify our current situation. Resolving the vote without such a clarification does not help this. You should all see an option below which you think is the Status quo, but I'm certain that not everyone agrees with which one, so, if you want the status quo, please vote for the option which describes it, not for further discussion. If you _can't_ see what you think is the status quo below, now is the time to point this out. (note, I'm not formally proposing this as a vote yet, but would like to fairly soon) I think trying to propose many options together is very wrong as you are very probably not objective for all the options nor will you be able to word it properly for the ones that do care about an option you don't really care about. The other risk you take by proposing many options at once is to mix unrelated things in the same vote IMHO. Option 1 - No Supermajority We do not believe that we should require anything more than a simple majority for any changes to the constitution or foundation documents. - replace Constitution 4.1 point 2 with Amend this constitution - in Constitution 4.1 point 5, point 3, remove A Foundation Document requires a 3:1 majority for its supersession. This option amends the constitution and hence requires a 3:1 majority. I would be very surprised if this option would get enough seconds if you would propose it. Option 2 - All conflicting GR options require a Supermajority We believe that any GR which has an option which overrides some or all of a foundation document, even temporarily, implicitly modifies it to contain this exception and thus requires a 3:1 majority This all boils down to the definition of override which I tried to state in the other thread. If you go by my definition, this is really a non-option IMHO. Option 4 - Balancing issues between users and freedom We believe that there will be cases where the project must balance between our priorities of our users and of Debian remaining 100% free. Project decisions which make such a balance do not require a Supermajority, but all others do - Add Social Contract 6: 6. Works that our not 100% free but are required by our users. We acknowledge that there may be occasions where it is not possible to place the interests of our users first with purely free software. As such, we may on occasion provide software which does not meet our normal standards of freedom if it is necessary in the interests of our users. In all cases we will work towards a free system where such compromises are not necessary - replace Constitution 4.1 point 5 with Issue, supersede, withdraw, amend and add exceptions to nontechnical policy documents and statements. - in Constitution 4.1 point 5 add point 4: All GR options which provide exceptions to a foundation document (temporary or permanent) implicitly modify the document to contain that exception and require a 3:1 majority Same remark as above. This option amends the constitution and social contract and hence requires a 3:1 majority. This option does not look related to supermajority requirements to me. Option 5 - Temporary overrides without Supermajority We believe that GRs may temporarily override foundation documents without requiring a 3:1 majority. Resolutions which are in conflict with a foundation document and make a permanent change must modify the foundation document and require a 3:1 majority - replace Constitution 4.1 point 5 with Issue, supersede, withdraw, amend and add exceptions to nontechnical policy documents and statements. - in Constitution 4.1 point 5 add point 4: All GR options which provide permanent exceptions to a foundation document implicitly modify the document to contain that exception and require a 3:1 majority - in Constitution 4.1 point 5 add point 5: All GR options which provide temporary exceptions to a foundation document only require a simple majority to pass. This option amends the constitution and hence requires a 3:1 majority. This boils down to the definition of override again... Option 6 - Votes may modify or be a position statement, but must be explicit We believe that any vote which overrides a Foundation Document modifies it to contain that exception and must explicitly say so in the proposal before the vote proceeds. Such overrides require a 3:1 majority. This is already the case AFAICS A GR which explicitly states that it does not override a Foundation Document but instead offers a project interpretation of that Foundation
Re: Overriding vs Amending vs Position statement
Manoj Srivastava wrote: On Fri, May 01 2009, Don Armstrong wrote: On Fri, 01 May 2009, Luk Claes wrote: A position statement is a decided on proposal that clarifies the position of the Debian project, but does not explicitly amend a foundation document. [...] So I don't really see what we should vote on unless someone disagrees with above interpretations? The only question resides with the effect of passing such position statements. Without modifying foundation documents or the constitution, they are effectively non-binding advisory statements when operating within areas that are the remit of foundation documents or the constitution. Developers can ignore (or follow) such statements as they wish. If the statements are in contradiction of the foundation document (which is the case in a couple of prior situations), then are you saying that anything in the foundation documents can ve worked around by putting out a position statement, and have the developers proceed to ignore the foundation document on that basis? Of course not. If a position statement contradicts a foundation document it's time to update the foundation document accordingly or drop the position statement again. That also begs the question: do we _have_ to follow the foundation documents? Or can one just issue a statement I do not agree with the foundation doc and just ignore it at will? You do realise that a majority needs to agree with it before it turns into a position statement? It's not because a position statement is not binding that a foundation document would also not be binding... if that is not the case, what value does a position statement in contradiction of a foundation document mean? It would be a clear indication that the foundation document should get an update or that the postition statement should get dropped again. Can I just set a position statement that redefines all the owrds used in a foundation doc to promote my interpretation of the foundation doc, as long as the majority of the people voting rate it over FD? This is actually asking if a position statement can clarify a foundation document but put in a twisted way AFAICS... How binding _are_ the foundation documents? Interesting question as you seem to be one to take the Constitution with a twisted interpretation when it fits you best in some previous occasions. free === does not cost more than USD 1000300.73 distribute == transport over trains between sunday noon and monday morning 8:00am Guidelines === something that must be followed in the ides of march I guess this is a bad attempt at a joke? Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Q to Steve and Luk: sharing of workload?
Lucas Nussbaum wrote: Dear Steve and Luk, Hi Lucas So, you are running in tandem. How do you plan to organize the sharing of the DPL workload? I think we'll try to spread the workload depending on the circumstances of the moment. Will Steve be The DPL, with Luk only helping on some matters? Or will it be more like 50/50? For example, who will receive lea...@debian.org? We will both receive lea...@debian.org and will divide the tasks between us. Of course we will discuss with each other for important decisions and about who does what including feedback about what has been done. Steve will of course have the last word as he is the official DPL. So he certainly will correct anything I misrepresented above :-) Luk, you are already a very busy DD, with your Release Manager hat, and your work inside the buildd team, and SPI. Which of those roles will you temporarily give up during the DPL term? Your role of Release Manager is very important for the project, and many DD might not want to lose a RM: it's a very demanding and time-consuming position, and we might have problems finding another victim. Can you convince us that the Release team can survive without you? I think I'll be less active on most of them, though that does not mean the members of the mentioned teams have to lose me :-) I certainly will have to delegate more and find more people willing to do the 'ground work', though I think that's a good thing. Currently the RMs are doing a lot of day to day tasks, having more delegation would mean they could focus more on the communication and management both in the Release Team (and for me also elsewhere which is in line with the role of DPL assistant AFAICS). Btw, I'm certainly interested to know who is interested in day-to-day QA release tasks, in one of my packages, in buildd maintenance or in taking over other things I do, to relieve my workload. Please contact me in private and we'll try to work something out. Cheers Luk -- 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
MJ Ray wrote: Russ Allbery r...@debian.org 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. Did the delegates decide this particular matter or was Bug #495721 merely a summary of current practice? The statement there seemed incomplete in significant ways. Yes, they did. Also, I think we should let the secretary to decide if a GR proposal modifies some foundation document, overrides a delegate decision, or requires amendment to be valid, rather than withholding seconds. I'm not that great at bureaucracy, so I think it's better that only the secretary decides the rules, rather than having every DD try to use the rule book as a weapon. I think it's wrong to leave the decision on whether a GR proposal modifies a foundation document to the secretary. I do think it's a good idea to request withholding seconds if anything is unclear. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: All candidates: Membership procedures
Lars Wirzenius wrote: la, 2009-03-21 kello 01:42 +, Steve McIntyre kirjoitti: P.S. Damn, just read Zack's answer and we don't seem to differ very much. Oh well... :-) Dear Zack McIntyre, Steve Claes, and Luk Zacchiroli, What's your opinion on membership procedures? Last year there were some rough proposals for how to change the membership procedures. It started with Joerg's proposal, but other people suggested their own kinds of changes, including me. I feel that my approach and Joerg's are pretty much diametrically opposed. What's your opinion? Do you feel the current NM process works well and almost always selects for the kind of people that are really great for Debian? Would some other kind of process work better? What kind of membership process would you like to see in Debian in, say, a year from now? Please feel free to dream, there's no point in being too constricted by reality and practical considerations. I think we first have to think about what a member, if we need different types of access/members and what they would be before thinking about the process(es) to become a member. I do think for instance that contributers who spend a lot of effort in Debian (like for instance some translators) should be able to become a member and so be able to vote. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: All candidates: Membership procedures
Lars Wirzenius wrote: su, 2009-03-22 kello 17:01 +0100, Luk Claes kirjoitti: I think we first have to think about what a member, if we need different types of access/members and what they would be before thinking about the process(es) to become a member. I do think for instance that contributers who spend a lot of effort in Debian (like for instance some translators) should be able to become a member and so be able to vote. Translators can already become members of the project, as far as I know. It's already possible, though not it's not very known nor easy for a translator to become a DD AFAIK. For the rest of your answer, I must admit I remain in the unclear about what you think, Luk: the questions you raise are certainly questions that should be raised in this discussion, but do you have answers or opinions on them, even if preliminary? I'm not looking anything set in stone, but I'd like to know what the candidates think on these issues. Do you think the current process if mostly fine, or you think it needs to be scrapped and re-created from scratch? Or something else? *The* current process is not very obvious to me as there is the DM process for limited upload rights and the NM process to become a DD (access to machines, upload rights, voting rights, some extra benefits like the email address). I think it's wrong to make totally separate processes with gross hacks in core tools of our infrastructure to support multiple types of membership. So I do think that the questions I posed are to be answered first before rethinking details in the processes: there first needs to be a global picture. I do think that the current DD and DM statuses are not the only types of membership there should be or not necessarily in its current form. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
Stefano Zacchiroli wrote: On Thu, Mar 19, 2009 at 05:39:38PM +0100, Stefano Zacchiroli wrote: Collaborative maintenance should not be mandatory (we do have several very efficient one-man-band developers), but should be our default. snip What I would do if the times will come, is to get in touch with NM people. My proposal would be to add a join a team entry as one of the *recommended* step in our join checklists. I agree that this is a good idea. Some documentation is very focused on packaging new software, where existing teams are already having a hard time to keep up maintaining important packages. I think both for the existing maintainers as well as for the NM it's very probably more rewarding to work together on existing packages. Let me add a second way to implement that default; I've split it in a different mail because it touches a different subject: handling of sub-standard quality packages. We need ways to identify them and to, initially gently and then more forcibly if needed, encourage maintainers to pass over maintenance. How to do that is a different topic, let's assume we have a way to identify such packages. I think it's important to foremost work together with the maintainer on this. The goal should be that the maintainer is more proactive in the future and we would not get sub-standard quality packages for them that easily anymore. In such scenario, the first choice should be to look whether we already have a team maintaining related packages and get actively in touch with them to check whether there are people in the team willing to take over maintenance. The second choice should be an attempt to create a team for the maintenance of the package, possibly federating together related packages. FWIW, that's how I got involved in several of the teams I'm a member of: responding to cries for help together with other. If all this fails, we should then put the package up for adoption as we currently do. I don't think it's a good idea to take over packages from existing maintainers unless that maintainer agrees with it or is not active anymore. Proposing the maintainer to join existing teams maintaining similar packages is a good idea though. Finally, I believe our most important packages (e.g., as defined by their archive Priority or shared libraries with tons of reverse dependencies) should be team-maintained, at least to provide backup maintainers. In fact, the PTS already implements such a warning on a Priority basis (implementation by Raphael, a while ago); similar warnings can and should be added to other tools of our toolchains. Not a bad idea, though it's only a 'should' and should not be interpreted as a 'must' IMHO. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Question for DPL Candidates: Debian $$$
Joseph Nahmias wrote: Hello Steve, Luk, and Zack! Hi Joseph Having just particpated in the latest SPI board meeting, I've learned that The Debian Project currently has over 125k USD in reserve. This amount (even setting aside the recent 30k debconf9 sponsorship by HP) seems to be at a point where we as a project should start articulating and coming to some agreement on what an appropriate level of reserves is, and how (on what) to spend the excess. Note that SPI is not the only organization holding money for Debian. The Debian Auditor has recently promised to give a complete picture in the near future... Given that both platforms stress the leadership and communication functions of the DPL, and that the DPL is the one specifically empowered by the constitution to decide (along with the membership) how that money is spent [§5.1.10], I'd like to hear some thoughts from all of the candidates on: 1 - What is an appropriate reserve level for the project? Currently project money is mainly used for hardware (most of it is donated though) and travel reimbursement. So there are almost no recurring expenditures. Worst case there would be a fast need of some thousands, so the reserve level needed is quite low. 2 - How should funds above that level be allocated? I think it could be spent more on organising meetings and maybe some clear instructions should be prepared to make that easier. Meeting people in person improves communication, makes it easier to work together even when only meeting online afterwards, ... so I think it should be the top priority for money expenditures. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Question for DPL Candidates: Debian $$$
Manoj Srivastava wrote: On Wed, Mar 18 2009, Joseph Nahmias wrote: 1 - What is an appropriate reserve level for the project? 2 - How should funds above that level be allocated? 3 - Should these decisions be made by the DPL acting alone, or should that be left to the project membership deciding collectively? I think the project membership is fine with having money spend on hardware and travel reimbursement in general. Excessive expenditures or expenditures on other items should be discussed with and agreed by the project membership before specific cases can be considered by the DPL IMHO. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Question for DPL Candidates: Debian $$$
Stefano Zacchiroli wrote: On Wed, Mar 18, 2009 at 09:24:29PM +, Joseph Nahmias wrote: 2 - How should funds above that level be allocated? Other potential usages of Debian moneys are bounties, to which I'm not opposed in principle. However, they should obey to very specific rules. The first one is that no one already contributing to Debian should be authorized to pick them up (no dunc-tank 2). The second one is that they should be used only for tasks that we have a history of not being able to fulfill by ourselves, and that are considered blocking for some needed Project improvements. No matter how people can get emotional about this, this would be way better that let money rot in our bank accounts; money that people who love us have given us to improve what we do. I don't think bounties are the answer. I agree however that money could possibly be spent on tasks where we find no volunteer for. Though I guess it will be hard to define such a task and would probably rather expend money on ways to find a volunteer anyway (advertisement, conference presence or whatnot). Cheers Luk -- 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
Matthew Johnson wrote: On Mon Mar 02 00:23, Matthew Johnson wrote: The votes around the Lenny release revealed some disagreements around the constitution, DFSG, supermajority requirements and what people think is 'obvious'. What I would like to do is clarify some of these before they come up again. To avoid overloading -project I'd like to move the initial discussion somewhere else. If you are interested in developing the ballot options for this, please follow up on -vote. We'll move back to -project when there are more firm suggestions. Hmm, so far the discussion has been rather less verbose than when the issues were blocking Lenny. While not having arguments is good, I really do think we need to make sure we don't have the arguments again for squeeze. My previous email tried to cover the whole field of views, this one is my personal view, which I want to run to a GR to make the constitution and FDs explicit on the points which were ambiguous in the discussions pre-lenny. I think the reason there were no comments is just because you tried to cover the whole field, I would rather take one point at a time. Overriding vs Amending vs 'Position statement' When a GR has an option which contradicts one of the foundation documents, but doesn't explicitly amend it; does this count as amending it? If it does not, then how is this reconciled with the fact that we have just agreed to do something which would contravene our own foundation documents? This is the difference between a goal and pragmatism AFAICS. It's not because we have a position statement that *temporary* contradicts a foundation document, that we want to amend the foundation document. I personally believe that any vote which contradicts one of the FDs, even if just a temporary or limited scope exception, implicitly modifies that FD and therefore requires a supermajority. Such votes should be included (probably via a hyperlink) in the FD itself. I guess that would mean we should rethink all the foundation documents as many items are currently already contradicted in practice... - Ballots which are ambiguous about resolving the clash between them and a FD should be rejected and not run. I also believe that the secretary should have the power to refuse to run a ballot option (by delaying the vote as appropriate) if he believes that it contradicts a FD but the ballot option itself does not explicitly claim to or otherwise resolve this problem. I don't see what this power to refuse would by us other than getting a similar situation we had with the previous Secretary? I would rather give the Secretary the power to delay a ballot for a limited amount of time to actively try to clarify the ambiguity. Release team vs DFSG issues This is a very unfortunate way of looking at things IMHO. DFSG applies to sid. If it's there and no-one has removed it, the RT can snapshot the archive at any point for the release. DFSG or other RC bugs; it's up to them whether to ignore them. This is possibly a subset of the above two items, however, I think it's important enough to warrant being explicitly specified. If a known DFSG issue is in sid, that means there is no problem with distributing it (or the FTP Team is not acting). By the way if the Release Team would ignore DFSG issues, one would not find a Release Team action that shows this fact. Tagging them release-ignore, is not ignoring the bugs, but telling our developers that we don't think the issue should delay the release. This tagging is of course only done when it's clear that there is being worked on the issue, but that it's very unlikely that it would be finished before the release. Note that tagging bugs release-ignore does not at all mean they cannot be fixed before the release. On the contrary, it means that fixes for them are still accepted, but when the fixes are not in time for the release, we're not going to wait for them. WRT the other issues, I'm happy with the seconding and supermajority options as they are, so won't be proposing we change them. So is Dato leading the discussion for these other options? Cheers Luk -- 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
Matthew Johnson wrote: On Sat Mar 14 12:14, Luk Claes wrote: I think the reason there were no comments is just because you tried to cover the whole field, I would rather take one point at a time. Sure, please do follow up with separate emails if you prefer. Hmm, I thought you were going to lead the discussion and not just send a IMHO giant proposal to be commented on. I also believe that the secretary should have the power to refuse to run a ballot option (by delaying the vote as appropriate) if he believes that it contradicts a FD but the ballot option itself does not explicitly claim to or otherwise resolve this problem. I don't see what this power to refuse would by us other than getting a similar situation we had with the previous Secretary? I would rather give the Secretary the power to delay a ballot for a limited amount of time to actively try to clarify the ambiguity. No, Manoj believed (correctly or no) that he should mark them as super-majority if he thought they contradicted an FD, which the people who posted them disagreed with. I'm saying that the secretary can delay (possibly indefinitely) such a vote until it's made explicit. Well, this is far from easy as even if you say explicitly that it does not contradict, some people will still think it contradicts. So then we're at a point we need to know who can decide about one or the other? (I think we actually agree about both of these issues) If a known DFSG issue is in sid, that means there is no problem with distributing it (or the FTP Team is not acting). By the way if the Release Team would ignore DFSG issues, one would not find a Release Team action that shows this fact. Tagging them release-ignore, is not ignoring the bugs, but telling our developers that we don't think the issue should delay the release. Yes, this is what I think and tried to say in my previous mail. WRT the other issues, I'm happy with the seconding and supermajority options as they are, so won't be proposing we change them. So is Dato leading the discussion for these other options? Anyone who wants to change them. I tried starting off that discussion, but noone followed up. I'm not about to propose running a vote to keep them as they are... Hmm, I thought the reason we delayed it till after the release is so we could discuss things and only when we have a consensus to change or seem to have clear options, to get to a vote. As I saw your name mentioned next to the constitutional issues, I thought you were going to tackle one point after another to lead the discussions and not just to try to defend your own views? Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Question for all candidates about http://wiki.debian.org/DiscussionsAfterLenny
Charles Plessy wrote: Dear Steve, Luk and Stefano, Hi Charles thank you very much for the time and efforts you are proposing to dedicate to the Project ! Our Consitution suggests a stronger leadership of the DPL the discussions: 9. Lead discussions amongst Developers. The Project Leader should attempt to participate in discussions amongst the Developers in a helpful way which seeks to bring the discussion to bear on the key issues at hand. The Project Leader should not use the Leadership position to promote their own personal views. http://www.debian.org/devel/constitution.en.html#5 Given how heated discussions can become in Debian, it seems that many previous Leaders have chosen to have a cooling role rather than a conducting role. Nevertheless, how do you intend to act in the context of this 5.1.9 article if you are elected ? In particular, there is already a long list of subjects on the Wiki. Can you comment about it ? I would try to have people already involved in the discussion lead the discussions and help them where needed (like I just did for the Constitutional Issues thread). I think the wiki page is a very good initiative and hope it will be used to keep track of what discussions need to happen and to keep track of their status. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: General resolution: Clarify the status of the social contract
Manoj Srivastava wrote: Hi, I like the idea of clarifying what the principles of the project actually are, since, as aj said, all the decisions about lenny would fall out from the position the project take about the foundation documents. While I have always thought that foundation implied the proposal below, apparently this is not a universally held view. You want to clarify what the principles of the project really are and all you talk about is point 1 of the Social Contract??! Maybe you take the other points for granted, though it surely looks strange to me. I also think it's rather strange to talk about binding and non-binding regarding 'Guidelines'. As long as it are guidelines, the question will always remain how to interprete them in any circumstance AFAICS. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Manoj Srivastava wrote: On Wed, Dec 17 2008, Luk Claes wrote: Manoj Srivastava wrote: On Tue, Dec 16 2008, Matthew Woodcraft wrote: If the proposer of vote/2003/vote_0003 had intended it to give the Secretary power to impose supermajority requirements on the grounds that an option conflicts with a foundation document, one would have expected him to have said so explicitly. So, in your opinion, which decision making entity is empowered by the constitution to make decisions about super majority requirements? What are the constraints on their ability to decide on this? What should they be looking at, apart from the constitution, to decide whether a super majority rule should apply? I would think the explicit overriding or removal of parts of foundation documents aka changing them as I read it in the constitution (but apparently my interpretation differs from yours). Parse error. Which entity did you mean? Or are you just answering the last question? Does that mean we can just not follow the foundation documents by doing something different, but just not saying explicitly we are over riding them? Nope, position statements are more like statements telling how to interprete foundation documents, noone is trying to change them. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Manoj Srivastava wrote: On Sun, Dec 14 2008, Pierre Habouzit wrote: On Sun, Dec 14, 2008 at 03:02:17AM +, Debian Project Secretary wrote: And FWIW I still believe this vote is an horrible mix-up of really different things, is completely confusing, and I've no clue how to vote. I would be surprised other people don't think the same. E.g. How can I decide 2 _and_ 4 ? Does the rule change ? Does any resolution that wins overs Further Discussion will be validated ? Because unless I'm mistaken, 2 doesn't imply 4, so if 2 wins, 4 is invalidated. No one seems to have seen it desirable to put a 2 4 option on the ballotl; despite the months we took to discuss this. The web page with the options was also up for several weeks, and a draft ballot went up earlier. It's you who decided to put all the proposals on the same ballot. I don't think it's fair to request from people who disagree with that to invest time in proposing more options. It's you who decided to make it a mess, you could as an experienced vote taker have suggested quite some different things which could have made it cleaner instead IMHO. Seems liek there was plenty of time to change things, and add some of the power set options on to the ballot. If I had added options willy-nilly, you would have screamed again of abuse of power. Sure, though you could have followed the procedure or hinted people in an even saner direction IMHO. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Manoj Srivastava wrote: On Wed, Dec 17 2008, Luk Claes wrote: Manoj Srivastava wrote: On Sun, Dec 14 2008, Pierre Habouzit wrote: On Sun, Dec 14, 2008 at 03:02:17AM +, Debian Project Secretary wrote: Seems liek there was plenty of time to change things, and add some of the power set options on to the ballot. If I had added options willy-nilly, you would have screamed again of abuse of power. Sure, though you could have followed the procedure or hinted people in an even saner direction IMHO. I followed the procedure that I think we have followed in the past. We do ont make people jump through and replace all the words in the proposal by these words hoops, and we put related proposals on the same ballot. Unfortunately, some of the proposals are not mutually exclusive, so combinations are possible; and I did not want to increase the size of the ballot with combinations; I think had I done that, there would still have been accusations of the ballot being too complex. Right, this kind of makes your above point moot IMHO. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Manoj Srivastava wrote: On Sun, Dec 14 2008, Russ Allbery wrote: Bas Wijnen wij...@debian.org writes: On Sun, Dec 14, 2008 at 12:59:12PM -0800, Russ Allbery wrote: It's a shame that the vote was handled in the way that it was, Actually, I think the secretary has done a very good job in preparing the ballot. I would like to feel that, but unfortunately, I don't think the facts support that feeling. The 3:1 majority part I can understand. That's his job, and whether I agree or not, I can't get upset at him for doing his job. However, there are several other serious irregularities in this vote: * Why does releasing despite DFSG violations require a 3:1 majority now when it didn't for etch? It's the same secretary in both cases. What changed? I didn't find any of the explanations offered for this very satisfying. The proposal we used before is choice 5 in the current ballot, and that does indeed have a 1:1 majority like we did before. The devil lies in the details (and I have explained the details before too) -- which is that we state that the fiormware blob be released under a DFSG free licence. This means we explictly conform to the DFSG, Without that clause, in choice 2, we are just accepting any firmware blob, with any license, which means that we are allowing for the DFSG to be violated I do not think we released before with known violations. We released with things we strongly suspected as being violations; since we strongly suspect the blob was not the preferred form of modification, but we do not know for a fact. How is this different now btw? * Bundling the vote against the open opposition of a fairly significant number of people, including some of the people whose amendments were grouped together, is within his power but comes across poorly. There wasn't much attempt to compromise or discuss this, and I came away from that with a bad taste in my mouth. Have we not been discussing this for weeks now? Related options belong on the same ballot. Not doing so allows for strategic voting to game the issue. This is not really an opinion piece, this is a known flaw of splitting votes where condorcet is used. Because you seem to only have considered splitting the vote with the existing options and have no where suggested it would be better to split the options by topic and ask if the proposers and seconders would feel that was more appropriate... I am sorry about the bad taste in your mouth, but unless you can argue how we can guard against gaming the system when we split votes, I don't see where we are going with this. See above. * One role of the secretary is to interpret the constitution. The constitution states fairly clearly the process of decision-making for decisions of this type, such as whether a given package violates the DFSG, or how to weigh the implications of the Social Contract. Yet that decision-making process is not reflected in the ballot or in the presentation of the options. Option 1 is either meaningless or an override of a delegate decision, but the ballot doesn't reflect this. While the options are not written by the secretary, and people would consider it a gross abuse of power if I wrote things up as I felt thy should be written; the proposer could have made the overriding the decision of a delegate explicit. You could have made it clear that's how you interpret things and offered the proposers and seconders to think about changing it? Usually, the ballot form is created by the proposer, it contains the title of the proposal, as the proposer set it, and any majority requirements. Unless the proposer does not set it, then it *seems* to me at least that you try to come up with something without actually consulting the proposer and seconders. Option 4 looks equivalent to FD if you look at the decision-making process in the constitution, but the ballot doesn't reflect that. I think some additional clarity around that would have been very helpful. Again, the proposers or seconds could have improved the proposal. What does this have to do with the secretary. The secretary is supposed to have experience in taking votes and could suggest improving the proposal to the proposer and seconders? So, no, I think in this case Manoj did a poor job of preparing this ballot. (That doesn't mean that I have any problems with him personally, nor do I believe that he did so out of any ulterior motives. I think he made the decisions that he thought were correct. I just don't think they were good decisions.) Point 1 has been answered; and again today, point 2 is related to not splitting of related proposals or candidates for resolving the release into spearate vote while we use condorcet, and point 3 is unrelated to decisions I took; heck, I'd love to rewrite proposals other
Re: First call for votes for the Lenny release GR
Manoj Srivastava wrote: On Tue, Dec 16 2008, Steve McIntyre wrote: On Tue, Dec 16, 2008 at 04:27:22PM -0800, Russ Allbery wrote: This is where I have a strong disagreement with Manoj and apparently with you. I don't think there's any justification in the constitution for requiring a developer statement about the project's sense of the meaning of the SC and the DFSG to have a 3:1 majority, or to make a developer override to enforce that sense of the meaning. Both the override and the statement about the meaning of the documents should require 1:1. 3:1 should only be required when the documents are explicitly superseded or changed, not just for making a project statement about their interpretation. And that's my interpretation too. I think the constitution is quite clear here. Frankly, if you want a non-binding position statement you should make that explicit; the developers resove via a general resolution actions that go against a foundation document need the supermajority, in my opinion. Well, apparently not all DDs concur with that interpretation, though you have the explicit power to interpete the constitution, so be it (these DDs should probably explicitely propose something to maybe change the constitution). Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Manoj Srivastava wrote: On Tue, Dec 16 2008, Matthew Woodcraft wrote: Russ Allbery r...@debian.org wrote: If there were something in the constitution detailing decision-making process around foundation documents and their interpretation, it would have made this whole conflict easier to resolve. But so far as I can tell, there isn't, apart from application to voting specifically. There isn't anything in the constitution about the application of foundation documents to voting either, other than the rule about superseding them. If the proposer of vote/2003/vote_0003 had intended it to give the Secretary power to impose supermajority requirements on the grounds that an option conflicts with a foundation document, one would have expected him to have said so explicitly. So, in your opinion, which decision making entity is empowered by the constitution to make decisions about super majority requirements? What are the constraints on their ability to decide on this? What should they be looking at, apart from the constitution, to decide whether a super majority rule should apply? I would think the explicit overriding or removal of parts of foundation documents aka changing them as I read it in the constitution (but apparently my interpretation differs from yours). Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: call for seconds: on firmware
Manoj Srivastava wrote: On Tue, Nov 18 2008, Marc 'HE' Brockschmidt wrote: Robert Millan [EMAIL PROTECTED] writes: On Mon, Nov 17, 2008 at 08:08:36AM +0100, Andreas Barth wrote: Though I agree that the release team cannot put any foundation document aside, I don't think the release team is overriding the social contract, but chooses a certain interpretation (that I think is the correct one btw). Other people obviously prefer a different interpretation, and so the relevant question is: Whose interpretation is the binding one? Currently, it seems to me that unless decided otherwise by a GR, the release team has the final say (as explained by Russ). When you say chooses a certain interpretation, are you referring to the one in which SC #4 is interpreted in a way that cannot be complied with no matter what, only to use this impossibility as proof that SC #4 and SC #1 contradict each other, and in turn resolving that because the SC is inconsistent, SC #1 is meant to be read figuratively? I discussed this with Andi in the past, so let me answer: From our point of view, SC#4 is relatively clear: Our users need to be able to use a stable release of Debian and the free software community (not free software!) needs us to spread the use of _free_ software. Driving off people to another distribution because we have found yet another sequence of magic numbers that might, or might not, have source code somewhere is a clear violation of SC#4 in our eyes. It is your Myopia about §5 that is distressing; you seem to selectively read the SC as it benefits your views. , | 5. Works that do not meet our free software standards | | We acknowledge that some of our users require the use of works that | do not conform to the Debian Free Software Guidelines. We have | created `contrib' and `non-free' areas in our archive for these | works. The packages in these areas are not part of the Debian | system, although they have been configured for use with Debian. We | encourage CD manufacturers to read the licenses of the packages in | these areas and determine if they can distribute the packages on | their CDs. Thus, although non-free works are not a part of Debian, | we support their use and provide infrastructure for non-free | packages (such as our bug tracking system and mailing lists). ` The SC never said that we include things that violate DFSG #2 , | 2. Source Code | | The program must include source code, and must allow distribution in | source code as well as compiled form. ` Note that firmware is no program AFAICS... to be in main; it even states that `contrib' and `non-free' areas in our archive have been designed for that. This selective reading of the SC is one reason I believe the release team is in violation of the social contract. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Paul Wise wrote: On Sat, Nov 15, 2008 at 8:24 PM, Kurt Roeckx [EMAIL PROTECTED] wrote: Does this mean that even if the blob is GPL'd, we don't need sources for it? That sounds like it would be a GPL violation. Only if the blob is not the actual source, no? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discussion period: GR: DFSG violations in Lenny
Debian Project Secretary wrote: ,[ Proposal 2: allow Lenny to release with proprietary firmware ] | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` Wrong, the release doesn't decide what's in the archive or not. Debian is more than the releases although you seem to think it's not? So in no way is a decision about the release without talking about the archive in all its components going to override the SC. ,[ Proposal 3: (allow Lenny to release with DFSG violations ] | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` Same here. ,[ Proposal 4 ] | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` Same here. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final call for votes for the debian project leader election 2008
Joey Hess wrote: Adeodato Simó wrote: I, too, think that the quoted sentence above from Manoj is just plain inappropriate in a message sent with the Secreatary hat on. I personally, don't belive in this hat concept that seems to have infested the project. When I write a mail, *I* am writing the mail, it doesn't matter in what capacity I am doing so. I also don't wear hats[1]. Yes, you also don't use different email addresses in the From-header, do you? Everything that is sent as [EMAIL PROTECTED] is seen as official posts from the project just like things sent from [EMAIL PROTECTED] only in different capacities... I hopefully won't post more to this thread, though I'd be curious to know if other people think the above is just fine to say on d-d-a, or just don't care at all, or else. I like to see people being themselves on d-d-a, and not some simalacrum of a role that they're pretending has ursurped their personality. I guess I also should send some personal opinions about some packages (or maybe even maintainers) in the Bits from the Release Team... I really don't get why people think it *is* appropriate to include personal opinions in these kind of posts... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final call for votes for the debian project leader election 2008
Manoj Srivastava wrote: On Sun, 13 Apr 2008 09:49:22 +0100, Jurij Smakov [EMAIL PROTECTED] said: On Thu, Apr 10, 2008 at 08:15:36PM -0500, Debian Project Secretary wrote: The last time we had such a low turn out was in 2001, and then we only had less than one third the number of developers. Yes, shortening the voting period has been such a *fun* experiment. I think that using official project announcements as a medium to express your personal opinions is highly inappropriate, not to mention The first part of the quoted text is fact, not opinion. The second part _is_ personal opinion; though. You did not find the reduced interval fun, I take it? Does not matter at all... that the message itself, in its sarcasm, is very disrespectful of the entire community which voted upon this change. You are entitled to your opinion. I certainly do not cater to your point of view, thankfully. If you find that opinions that reducing the time interval for voting might be reducing the turnout to be insulting, then hey, *I* think you have a thin skin, and you might have to live with people expressing such opinions. You can express your opinions on this list without any problem, though your opinion should not be expressed in an official reminder to vote as that can be interpreted as influencing the vote. In some institutes you would be fired as Secretary for doing that... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final call for votes for the debian project leader election 2008
Manoj Srivastava wrote: On Sun, 13 Apr 2008 22:58:34 +0200, Luk Claes [EMAIL PROTECTED] said: You can express your opinions on this list without any problem, though your opinion should not be expressed in an official reminder to vote Why not? I hold these opinions about the processes I am following as a secretary while wearing my hat as a secretary. I have held opinions about the state of the vote for almost every vote held, and every non-initial CFV has had a paragraph detailing the state of the vote, and what I felt about it. Just because I am wearing an official hat does not mean I can't have or express _any_ opinion. as that can be interpreted as influencing the vote. This I consider silly. Thinking that the shorter voting period might have influenced participation somehow skews the vote for the DPL? Dow sending the CFV 24 minutes after the hour also skew the votes? Or sending the CFV when the influence of mars is rising in the house of Jupiter somehow tell people who to vote for? No, mentioning your opinion about the length of the vote in the call for votes can influence how people vote... In some institutes you would be fired as Secretary for doing that... Thank the Lord I do not belong to any such institute. On the other hand, if you feel like firing me, feel free to proceed. I didn't think it was worth mentioning, though you acting as if it's a normal thing to do provoked me to make you aware of it... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: All Candidates: Do you plan to be prominently visible during your term?
Marc Haber wrote: What is your plan to ensure your ongoing visibility during your term? Do you plan to post regular bits from the DPL, and which measures will you implement to prevent a failure similiar to the failures of your predecessors? You seem to value visibility more than achievements... I'm not so sure I would qualify a lack of visibility as a real failure, though I obviously value achievements more :-) I think it's very important that candidate DPLs have the intention to do better in communication, though I think many people underestimate the time and efforts it takes to communicate... Note also that visibility can also be very negatively or not at all related to being a DPL... I would rather rephrase the question to: What is your plan to ensure ongoing communication about your (progress towards) DPL achievements? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Constitutional amendment: reduce the length of DPL election process
Anthony Towns wrote:
=
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is None
Of The Above.
8. The Project Leader serves for one year from their election.
=
Seconded.
Cheers
Luk
signature.asc
Description: OpenPGP digital signature
Re: The Debian Maintainers GR
Raphael Hertzog wrote: On Sat, 28 Jul 2007, Andreas Barth wrote: * Raphael Hertzog ([EMAIL PROTECTED]) [070728 14:57]: On Sat, 28 Jul 2007, Andreas Barth wrote: However, in the DM case, you didn't speak first with the people knowing about the issues, but tried a rewrite from scratch. Historically, the project was only a project of an ftpmaster (Anthony). Once he wanted to deploy it, there has been some internal objections from another ftpmaster. Since ftpmasters couldn't take a decision alone, Anthony decided to ask the project approval with this GR. Anthony publically spoke of his project at several points in time and all the people involved in NM sure had noticed the discussions on debian-project. I would have like some more participation from them but the few messages I've seen involve skepticism and not a willingness to integrate the good stuff in NM. Which could very well indicate that they don't really like to be passed. The proposal looks much more a fork than the non official buildds do... There has been at least two alternative GR proposals but none got seconded, and the NM people could have drafted an alternative proposal to ask the project to implement something more sensible in their opinion. None of this happened, you can't blame Anthony for that. Why not, he didn't ask for any reaction from FD, NM or DAM before proposing, so I very much blame him for not having a good proposal in the vote... I'm sorry if you feel that the current vote is sub-optimal, but you should have gotten involved earlier. In the mean time, this vote involves only acceptance of the 'principle', the real implementation can evolve and possibly get integrated into NM (exactly like sponsorship got integrated in NM after sponsorship got created). If it's only about the principle, why is the proposal concrete about so much details? Sorry, but that doesn't sound at all *only* about the principle... The option that looks best to me to vote for is indeed further discussion... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GR PROPOSAL : The Debian Infrastructure is owned by the whole Debian project, and not a few select individuals.
Hi Sven As you are suspended for one year, your proposal is not valid according to [1] as your key is not in the keyring. Please stop pestering us with this childish behaviour. It's not because you make you very difficult to work with and as a result loose some priviliges that every DD should have access to the whole Debian infrastructure... Cheers Luk [1] http://www.debian.org/vote/howto_proposal Sven Luther wrote: By this resolution, the Debian Project resolves that : = START OF THE GR text = - No part of the Debian Infrastructure, is the sole province of a few select Debian Developpers, but is under the responsability and ownership of the project as a whole, and thus of each individual Debian Developper. - The Debian Instrastructure, includes, but is not limited to, the different Debian owned machines, the autobuilders, the archive, the mailing lists, the different source repositories, hosted at alioth or somewhere else, the core debian related projects at alioth or elsewhere, the mailing lists, the irc channels, the different teams, ... - As thus, no Debian Developper can be negated access of a ressource of the Debian Infrastructure. It is acceptable, for security reasons, that not every Debian Developper has access to some of these ressources, but if he request such an access, he should obtain it in a timely fashion (no less than two weeks). = END OF THE GR text = Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GR PROPOSAL : The Debian Infrastructure is owned by the whole Debian project, and not a few select individuals.
Sven Luther wrote: On Sun, May 27, 2007 at 05:57:54PM +0200, Luk Claes wrote: Hi Sven As you are suspended for one year, your proposal is not valid according to [1] as your key is not in the keyring. I don't recognize the suspension as valid, and furthermore, if enough DD second the GR it is valid. No, it's not as you could have read in the reference I pointed you to. Please stop pestering us with this childish behaviour. It's not because you make you very difficult to work with and as a result loose some priviliges that every DD should have access to the whole Debian infrastructure... Every DD that wants to work on a given area of debian should be allowed to do so, why should some be more privileged than others ? We all joined Debian thinking each DD is equal in right and duties, and that we would not hide problems, and then we face repeated case of a few select people having power, and manipulating things in the darkness. You don't need alioth access to be able to work on it. Just look at the arm buildd mess, or any of the numerous case of power-play over this last year. The arm buildd mess you probably are referring to was not caused by power-play, but by bad communication in two directions. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question to all candidates: officiousness
Clint Adams wrote: On Wed, Mar 07, 2007 at 05:43:41PM +0100, Wouter Verhelst wrote: I'm not sure what you mean by this question, or what the point is. I will clarify. AJ obviously feels that it is his prerogative (under which hat or set of hats, I do not know) to decide which set of architectures in the archive are worthwhile, and what manner of supplication or wowing is necessary to change his preconceived notions on these matters. He just argued why he is not convinced the port is ready for inclusion in the archive. [rambling about amd64] Most candidates seem to think that the kfreebsd port is worthwhile and should be included in the archive, but AJ seems to have additional requirements beyond what is listed for release architectures at http://release.debian.org/etch_arch_policy.html , and though it seems somewhat strange that the archive inclusion criteria should be stricter than the release arch criteria, I can see a point to introducing chicken-egg problems there. Indeed, it's only logical to have high standards (possibly higher than release arch criteria) for inclusion in the archive. Though I think most of the points AJ mentioned are easy to tackle for people working on the port... Now it is unclear which hat AJ is wearing when he implies that he is authorized to decide which architectures are important, by criteria he decides unilaterally. I am curious as to what the other candidates think: is it appropriate for him to do this, and, if so, which positions of authority or achievements have earned him the moral right to do so? ftpmaster As for the point of my question: I find this behavior to be highly arrogant and offensive, and will be ranking AJ below NotA because of it. In order to vote fairly, it is important to know the attitudes of the other candidates in these matters. Some of AJ's wording in this thread might be interpreted offensive, though I don't think that's intentional. He just listed his concerns which I hope will be acted on so that we have an extra high quality arch to support for lenny :-) Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Bits from the 2IC
Joey Schulze wrote: Holger Levsen wrote: Hi, On Tuesday 20 February 2007 15:56, Gustavo Franco wrote: It wasn't too polite from Steve, IMHO. He lost a great opportunity to avoid use d-d-a to promote his campaign even before the campaign period starts. Please Martin, just check the timing of the things and how it was planned. While I do think it would have been better, to first send the bits and then the nomination, I believe it was an honest mistake. And in a way I'm glad that Steve (DDs running for DPL in general) is not a perfect politican ;) Not to forget that his summary was long awaited already and he would probably have sent it independent of running for DPL or not. In the end it's probably just MJ Ray campaigning for Steve by making that line more visible to the voters... Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Asking for the ban of Frans Pop from debian-vote ... (Was: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware)
Sven Luther wrote: Hi list masters and DPL, Hi Sven Since it seems Frans is not able to leave ad-hominem attacks out of this discussion, and given the precedent of my ban from -release on similar issues, i now officially ask for Frans Pop to be banned from debian-vote, until such a time as he is able to discuss issues, without being able to resort to ad-hominem and defaming attacks like he has done here, even if in a slightly disguised form. Mails like his don't help the issue to be solved, bring absolutely nothing, and are borderline insulting, and nobody want to go into another repeat of what happened last spring. Communication is always between two or more ends... Sven Luther On Thu, Oct 05, 2006 at 04:33:06PM +0200, Frans Pop wrote: On Thursday 05 October 2006 11:43, Frank Küster wrote: first of all, I wonder why so few people from the teams involved take part in this discussion. I assume one reason might be that they prefer IRC. However, debian-vote is the list that's supposed to hold the important information for the vote, isn't it? No, it is because everybody who is remotely reasonable (with a few exceptions who are mostly forced to stay involved because of their roles in the project) has long since become totally disgusted with this anal discussion and the people pushing it . I don't take part in the discussion as I think it's way too high volume to repeat points that were already brought to the list... Instead of a simple GR that leaves the decision with what is acceptable for Etch with the Release Managers, we now have a convoluted proposal that tries to do a lot more than was ever intended. So, no, I will not support the current proposal (though I may vote for it). And, no, I am no longer interested in participating in the discussion, As Frans is not interested in participating in the discussion anymore, I don't see what a ban would bring if it would be justified to ban him in the first place... The reason why you were banned from debian-release was mostly because of turning it in a discussion list which it is not intended for. The tone of the messages was something that made it clear that you were not going to stop sending such mails to the list... Cheers Luk PS: Sending Cc's to debian-release in the middle of a discussion is not very clever when you just get unbanned... -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Asking for the ban of Frans Pop from debian-vote ... (Was: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware)
Sven Luther wrote: On Thu, Oct 05, 2006 at 06:45:05PM +0200, Luk Claes wrote: Sven Luther wrote: Hi list masters and DPL, Hi Sven Since it seems Frans is not able to leave ad-hominem attacks out of this discussion, and given the precedent of my ban from -release on similar issues, i now officially ask for Frans Pop to be banned from debian-vote, until such a time as he is able to discuss issues, without being able to resort to ad-hominem and defaming attacks like he has done here, even if in a slightly disguised form. Mails like his don't help the issue to be solved, bring absolutely nothing, and are borderline insulting, and nobody want to go into another repeat of what happened last spring. Communication is always between two or more ends... Maybe, but then i don't see what such conversation brings if one party is acting in evident bad faith, and whose whole purpose is to hurt me and continnue making me the scapegoat in order to make my opinion count less. Please, stop this whining it doesn't bring you anything. I don't believe Frans is acting in bad faith, though he might still not trust you or even like you, but that's something totally different... As Frans is not interested in participating in the discussion anymore, I don't see what a ban would bring if it would be justified to ban him in the first place... He says that, but he will again try to attack me in such a way, he has been doing so repeteadly over these last month, altough always in insidious and hidden ways. I don't believe he will try to attack you, though he might be cautious and you may be felt as attacked because of that... The reason why you were banned from debian-release was mostly because of turning it in a discussion list which it is not intended for. The tone of the Because Frans ad-hominem attacked me in the first place (dismissing my opinion in the subject of module .udebs, and accusing me of having an hidden agenda). But then nobody saw anything wrong in that. Most people just want to work together, not reply to whining... Your accusations might be correct, though it doesn't bring you or the project anything if you keep repeating them... messages was something that made it clear that you were not going to stop sending such mails to the list... And the tone of Frans message makes it clear that he will not stop sending such mails to the list, maybe not in the immediate future I wouldn't count on that, people differ quite a bit... PS: Sending Cc's to debian-release in the middle of a discussion is not very clever when you just get unbanned... How was i to know i was unbanned ? Also, you have to be aware that Andreas Barth complained i didn't send information to the debian-release list concerning the new proposals, so what am i to do ? Andreas Barth asking you to send something to debian-release could be seen at least as a sign of being unbanned... You could send a notice about the proposals and maybe asking to join the discussion on debian-vote, but certainly not sending a Cc to debian-release in the middle of a discussion. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: What if you are not elected as DPL?
Steve McIntyre wrote: On Sat, Mar 04, 2006 at 10:08:22AM +0100, Luk Claes wrote: Hi DPL candidates Would you also try to reach the goals mentioned in your platform if you wouldn't be elected DPL? Please be specific if you think one of your goals can't be reached or helped with without being a DPL or a member of the DPL team. Firstly, my stated goals from my platform: 1 Communications within the project 2 Mailing lists and IRC 3 Training and NM 4 Openness within the project 5 Technical standards 6 Working effectively; asking for help I believe most of these can be worked on by anyone, although some of them (1 and 2) could really do with high-level support if they're going to take off. You didn't really answer my first question: Would you also try to reach these goals if you're not elected DPL? Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
What if you are not elected as DPL?
Hi DPL candidates Would you also try to reach the goals mentioned in your platform if you wouldn't be elected DPL? Please be specific if you think one of your goals can't be reached or helped with without being a DPL or a member of the DPL team. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
martin f krafft wrote: also sprach Adeodato Simó [EMAIL PROTECTED] [2006.01.10.0455 +0100]: Formally, the Debian Project will include in the main section of its distribution works licensed under the GNU Free Documentation License that include no Invariant Sections, no Cover Texts, no Acknowledgements, and no Dedications, unless permission to remove them is granted. I'm a late entry to the thread, please excuse. If we kicked all GFDL out of main, how many upstreams would reconsider their choice of licence? None? Few? Some? Many? I am - that short of seconding dato's proposal, but I believe that Debian is also in a position to make the world a better place by asking upstreams to rethink. Or am I being completely naïve here? You can second a proposal without voting for it if you just want to have it on the ballot! Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: How should None Of The Above be used?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Osamu Aoki wrote: | Hi, Hi Osamu | I have a technical question on how to vote for the DPL voting system for | the following example: | | | Suppose there are 3 candidates: | | * Mr. good | | * Mr. unsuitable | | * Mr. bad | | Basically I want only Mr. good to be elected. Otherwise, I think it is | | better to call there were no one for DPL. At the same time, if by | | chance Mr. unsuitable and Mr. bad are dueling, I want to cast weigh | | to Mr. unsuitable. | | Is this correct answer? | | [1] Mr. good | [3] Mr. unsuitable | [4] Mr. bad | [2] None Of The Above I think so. | As I read voting system, anything below None Of The Above is the same. Where did you find that? There is mentioned that None Of The Above isn't treated special AFAICT (so it is not the default option IMO). Cheers Luk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCSYqr5UTeB5t8Mo0RAq9AAJ9PoZ6iaccomG8OYyooXZ5KWiF25gCfS0Ck M39PDdJWAZoY9UHIg0fXme4= =R6N4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Vote for the Debian Project Leader Election 2005
Hi John Goerzen wrote: Well... So much for: 1) secret ballots 2) reading directions You should mail it signed, but not encrypted to [EMAIL PROTECTED] You might have the same problem [0] as some others [1] [2] [3]. You'll be listed [4] as a unique voter [5] if your vote arrives. Cheers Luk [0] http://lists.debian.org/debian-vote/2005/03/msg00835.html [1] http://lists.debian.org/debian-vote/2005/03/msg00822.html [2] http://lists.debian.org/debian-vote/2005/03/msg00844.html [3] http://lists.debian.org/debian-vote/2005/03/msg00850.html [4] http://master.debian.org/~srivasta/leader2005.html [5] http://master.debian.org/~srivasta/leader2005_voters.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes for the Debian Project Leader Election 2005
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Igor Genibel wrote: | On Monday 21 March 2005 00:24, Debian Project Secretary wrote: | |HOW TO VOTE [...] |Then mail the ballot to: [EMAIL PROTECTED] |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. Note that only unencrypted votes to the above address are considered. You can check if your vote is counted [1] as there is a list of the unique voters available [2]. | |- - -=-=-=-=-=- Don't Delete Anything Between These Lines |=-=-=-=-=-=-=-=- 46348448-74a5-40ae-a651-49704435ae8c |[ ] Choice 1: Jonathan Walther |[ 2 ] Choice 2: Matthew Garrett |[ ] Choice 3: Branden Robinson |[ 1 ] Choice 4: Anthony Towns |[ ] Choice 5: Angus Lees |[ ] Choice 6: Andreas Schuldei |[ 3 ] Choice 7: None Of The Above |- - -=-=-=-=-=- Don't Delete Anything Between These Lines |=-=-=-=-=-=-=-=- | If you want to make your vote public, you should at least Cc the proper address IMHO ... [1] http://master.debian.org/~srivasta/leader2005.html [2] http://master.debian.org/~srivasta/leader2005_voters.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCPpnS5UTeB5t8Mo0RAlEjAKC83Cbeu611qxy4TvCqW6BrKYsk3gCgjZ7Z 6yIqFUD5Zb45j8UUdY0/BIY= =GQ6b -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
