Re: General Resolution: Statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
Hello everybody, thank you for preparing this! Quick comments form somebody who does not have the time to follow debian-vote: "make the best system we can": Maybe this is a good opportunity to point at our social contract, to show to the readers who have no idea what Debian is how important that the statement is for us, and that it predates the discussions on the CRA. The word "upstream" appears for the first time in point 1b. I am unsure with people with superficial knowledge of what we are doing know what "upstream" means. "The social contract": maybe "Our social contract" is clearer? 2d as it is written feels anti-government, and why would governments listen the needs of an anti-government organisation? The point on centralisation is already made in 2c. It may be remindwd there that threat actors include unlawful governments (and that in EU there as as many governments as members). Then, I would suggest to center 2d on the protection of activists. Maybe it could be said that Debian accept anonymous contributions for that reason, and that (to my knowledge) the CRA does not take that kind of situation into account. "the EU aims to cripple": this is a strong statement that will annoy all readers who believe that the EU aims to make a better world and possibly reduce the support for and impact of the GR. Maybe "If accepted as it is, CRA will cripple" I hope you find my comments helpful. Even if the GR text does not change, I will vote for it anyway. Finally, the conclusion calls for exemptions for small businesses, but why not explicitely call for a clear excemption for large free software projects such as Debian, given all the uncertainty that the CRA would create. After all, we compete with commercial products, we aim to have users beyond our community, and we do send strong signals to our users that they can put a lot of trust on us. In that sense, it may be argued one day by others that we are doing some kind of commerce. Have a nice day, Charles
Re: Question to all candidates: rotation on positions of power
Le Thu, Mar 17, 2022 at 04:27:49PM +0900, Hideki Yamane a écrit : > > I'm sorry, but could you explain "what do you want to improve with > a term limit"? Good evening Hideki, I expect a term limit to increase rotation on the positions of power, with the following benefits: - reduce the risk of burn-out of the delegates, - motivate fresh people to have the ambition to serve in these positions, because it becomes predictable when driving seats become available, - motivate the current delegates to put their own replacement as part of their planning, making us more resilient to sudden (or chronic) unavailabilities, - increase the chances that those of us who keep a strong involvement over many years diversify their experience, knitting our different subgroups into a more harmonious society. - increase our chances that challenging ideas accepted. In brief, everything good (and everything bad) that "more turnover" is expected to bring in most of social structures where we evolve outside Debian. Cheers, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Question to all candidates: rotation on positions of power
Hi all candidates, thank you for running ! I have a question for you (and only you). What do you think of the reform of the Technical Committee that introduced a limit to the time people can serve in, and would you consider applying a similar policy to other positions of power in Debian? Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: FYI, Secret Ballots Proposal is Likely to Die for Lack of Support
On Wed, Feb 16, 2022 at 03:34:09PM -0700, Sam Hartman wrote: > > My take is there's not currently enough support on debian-vote to bring > it to a vote. > I'd want to see several additional people express support on debian-vote > before I'd feel comfortable proposing a GR. Hi Sam, thank you very much for your time spent on this issue. I really would like all votes to be anonymous in principle. Last year I blogged about the possibility to crunch our vote data and cluster DDs by affinity. While I did not manage to do it myself, I am uncomfortable with the idea that we provide machine-readable data that makes this kind of approach likely to succeed one day. http://charles.plessy.org/Debian/debi%C3%A2neries/DebianAnalytica/ Maybe the GR does not need to go deeply on the technical details and can simply state the principles, define who choses the implementation, and to what extend the final process can deviate from perfection. I do not mind making a couple of concessions with practical challenges, and if a few people have need to transiently access deanonymised data to prove that there was no fraud, no problem. I think that after enough time for the results to be accepted, the deanonymised data should be just deleted. I think that we can also remove the tally sheets from the past votes from our public servers. Sure, they will stay forever in the Internet Archive, but the point is that the amount, kind and scope of the data that we publish ourselves should match our view about pricacy. Not sure if we really have a consensus but I think that we should refrain from publishing personal data that does not serve a significant purpose. Have a nice week-end, -- Charles
Re: Draft GR for resolution process changes
Thanks Russ for keeping me in the loop, here are comments from my point of view in the hope of being useful, please do not take them as objections; I know that you have looked at the problem through many more angles than I did. By the way, sorry in advance if what I write today has been already addressed by others earlier. Le Thu, Nov 11, 2021 at 08:26:00AM -0800, Russ Allbery a écrit : > > Once a proposal has been sponsored and added to the ballot, we, as a > general social convention, stop sponsoring it unless it feels particularly > important to be listed as a sponsor. This practice of sponsoring over the necessary number has always made me uncomfortable. The more we give importance to the question of who sponsored, the more we put social pressure on the voters. This is another reason why I think that limiting strictly to 5 would be better. This said, anonymous voting (which I think is better to decide in a separate GR) would solve that problem entirely. > In other words, I think once a ballot option makes it onto the ballot, the > rules are attempting to capture the sense that it no longer belongs just > to its proposer, but now represents some unknown number of people who want > to vote for it. My conclusion with the 2008 GR is that removing the original option made it a better GR. The removal triggered the addition of new options, but none of them were identical to the original one. Perhaps it would have happened also even if sponsors had a veto, but I believe that personal responsibility is going to be more efficient than collective intelligence there. > Once people who have sponsored the original ballot option start > objecting, I think we should take that as concrete evidence that the > new option is sufficiently different that it may not represent the > people who were supporting the old option, and we should therefore > default to adding the new option via the normal mechanism. Fraknly speaking, I worry that some day somebody will sponsor as many options as possible and object to changes for the sake of adding toxicity to GR. The more members we have, the less unlikely it becomes. But even assuming good will, I think that a process that makes it easier to remove or merge options would serve us better than a process that makes it easier to fork options. A lot of GR voters do not follow the debates on debian-vote, and with too many options, possibly all written in different styles, there is an increased risk of voting for the contrary of what we want. Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Draft GR for resolution process changes
Hi Russ, thank you very much for proposing these changes. Overall they are very convincing and would already vote for it today, but there are two things that I wonder: - (Not just to you:) Would it be possible to test them in real befoe adopting them? Maybe with some kind of role-playing game where some random people are assigned adversarial roles? - About the sponsors, if there are too many, then the proposer is more at risk to face vetos when accepting amendments. (I write that as I accepted major changes as the proposer of a GR option some years ago.) Would it make sense to limit the total number of sponsors, and to only allow developers to sponsor one option ? Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Making the RMS resolution a Secret Ballot
I agree for the GR vote to be secret. I understand others came to a different conclusion. I trust Kurt for making the right decision. I will not complain about it. -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy signature.asc Description: PGP signature
Question to the DPL candiates: secret ballots
Dear Jonathan and Sruthi, I recently wrote on my blog « Like many GRs, it will divide Debian and leave scars, at least a tally sheet of who voted what, and who voted like whom. » I would like to elaborate and ask you: Would you as a developer agree to have all votes secret, and would you as a DPL invest some time into making this happen ? I think that our public votes are a vulnerability. We are in an era of data harvesting, global surveillance, and large-scale manipulations. I think that it would take little time to a junior analyst to compile the tally sheets of our GRs, delineate the cracks in our community and find on which people to press in order to push our project in directions we do not want (including implosion). Is that paranoia ? Between big totalitarian states that might supsect us of sympathy for their opponents, and big democracies of which we openly defy the intelligence agencies, I would not be so surprised that eventually, one tries to remind us to focus on being an excellent and gratis package supermarket for XXIth century IT businesses, and nothing more. Reality if of course more complex but I do not intend to write a whole essay, so please forgive me for being simplistic. This said, I think it is time to vote anonymously. I am looking forward reading your anwers ! Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: New General Resolutions.
Le Sun, Jul 10, 2016 at 03:52:51PM +0200, Debian Project Secretary - Kurt Roeckx a écrit : > > 2 new GRs have been started: > > - debian-private list will remain private: > https://www.debian.org/vote/2016/vote_002 Hi Kurt, I read "The proposal needs a 3:1 majority" at the URL above. Is there an explanation somehere why the supermajority is needed for this GR ? Or is that a cut-paste-accident while also working on the constitutional change ? Have a nice day, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
Re: More women in key positions ?
In order for the TC to recommend someone, they must first be nominated and accept, or nominate themselves. Claiming that the lack of women on the TC can be resolved simply by forcing the TC to do so is simplistic. It also seems to me to be insulting to the many highly skilled women in Debian with whom I would be happy to serve on the TC with, had they been interested in serving. Hi Don, I am well aware of how the TC works, and in particular I have been contacting people in private to encourage them to nominate themselves. If the discussion here would be about reforming the TC, I would propose that the nominations should be public, just as for the DPL election. In that way, it would be more obvious to everybody when no woman is candidate. However, the topic here is the DPL election, hence my question is focused on what the DPL can do, and one possible action is to use the appointment process to push for more women in the TC. This push can be as hard as refusing any appointment, but it can also be as soft as delaying the decision for one month, and sending one motivational email asking for more women as candidates. In that sense, I am not asking the DPL to force anything. But if the DPL could put a little bit of formal involvement into helping the TC to have women members, I think that it would be a great signal. Have a nice day, (PS: Please CC me, I am not subscribed) -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20150331000151.ga30...@falafel.plessy.net
More women in key positions ?
Hi Mehdi, Gergely and Neil, thanks for being candidates to this election ! You probably noted that no woman was candidate this year, and that no woman was appointed to the technical committee in the recent replacements. Do you think that it is a problem that there are no women in key positions in Debian ? If yes, what do you plan to ameliorate the situation as a DPL ? Have a nice week-end, PS: please CC me for your replies, I am not subscribed. -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20150321035005.ga10...@falafel.plessy.net
Re: Maximum term for tech ctte members
Le Sun, Nov 09, 2014 at 03:08:39PM +0100, Lucas Nussbaum a écrit : When replacing two members at a time, it might be a bit difficult to take that desirable balance into consideration. For example, if there are three candidates A - B - C in the shortlist, and A and B are basically clones in terms of profile, it would make sense to choose (A OR B) AND C. If the final decision is made via a vote, it could require to vote on pairs of candidates. Hi Lucas, actually, replacing two members at the time would give a good opportunity that at least one of the members is not a western male that is is fully fluent English speaker. While there is nothing wrong with that profile by itself, we are missing something when all the members have this profile. It is good to value technical excellence, but the work to be done in structures like the technical comittee needs other skills as well. I think that somebody who has a good capacity of synthesis, seeking advice, and understanding other people's points of view would also be very qualified. Said differently, I think that we give too much importance on who the TC members are, as compared as what they can do. Let's remember that the TC has a long backlog, so somebody who can learn and has time to do so will be more efficient than somebody who knows but has no free time. Rotating people by pairs would be a good opportunity to make it easier to introduce diversity in the technical comittee. (I am not suggesting to change the current proposal to ensure more rotations by pairs). Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20141110001313.gc13...@falafel.plessy.net
Unsubscribing - let's use mailing list bans more frequently.
I just suddenly wondered... How come Debian lists are trolled about systemd and not the lists on FreeDesktop.org ? I do not have an answer but in the short term I am unsubscribing from debian-vote and maybe debian-devel later, until we as a project find a way to fix our communication channels, which are outrageously biased in favor of people who just talk the whole day, and against the people who would like to use these lists to achieve something useful. This said, if our Project agrees to be more liberal on mailing list bans, especially short-term ones (like one or two weeks), I volunteed to re-subscribe on debian-vote again do some of the work. PS: CC me if you need further input on my side. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan. -- 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/20141110062120.ga5...@falafel.plessy.net
Re: How about always sending a copy of proposals, amendements, secondes etc. to the Secretary ?
Le Tue, Nov 04, 2014 at 06:45:55PM -0800, Don Armstrong a écrit : Those of us who propose amendments and proposals should really propose a ballot option name, amendment, and figure out who seconded the proposals and just send them to the secretary in wml suitable for direct inclusion in the appropriate vote_nnn.wml file. I don't think it's necessary to actually amend the constitution to do this, because it's just something that we can do. Le Wed, Nov 05, 2014 at 08:35:56AM +0100, Lucas Nussbaum a écrit : (on your other point, I agree that we could move the burden of collecting Seconds to the proposer.) Thanks for your comments. Indeed, modifying the constitution would be too much in the end. So the tentative conclusion of this discussion is that the Secretary is welcome to modify the voting instructions (https://www.debian.org/vote/howto_proposal) in order to transfer some of the procedural burden to the people proposing and amending general resolutions. Have a nice day -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20141106020546.ge12...@falafel.plessy.net
How about always sending a copy of proposals, amendements, secondes etc. to the Secretary ? (Re: Call for Votes: General Resolution: Init system coupling)
Le Tue, Nov 04, 2014 at 07:32:36PM +, Neil McGovern a écrit : This vote has currently used up about 15 hours of my time, plus the time to read -vote, and I really didn't want to wait up until gone midnight to post the CfV. Hi Neil and everybody, first, thank you Neil for the hard work on managing the vote on this GR. Would it help to amend point 4.2.5 of our constitution, to request that in addition to the announcement on a publicly-readable electronic mailing list, a copy of proposals, amendments, sponsors, etc. must also be sent to the Secretary ? It seems unfair to request the Secretary to read each and every email on debian-vote... I understand that changing the Consitituion is hard, but since there are other general changes under discussion, maybe there is an opportunity to bundle the most consensual ones... Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20141105004031.gb12...@falafel.plessy.net
Re: Reducing the discussion and the voting period to 1 week
Le Wed, Oct 22, 2014 at 05:22:39PM +0200, Lucas Nussbaum a écrit : Charles, Luca, can you confirm that you are also fine with shortening the discussion period to one week? I am fine with shortening it. Cheers, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan signature.asc Description: Digital signature
Re: [Call for seconds] The ???no GR, please??? amendement.
Thanks Anthony and Lucas for your suggestions. Even if it can be improved, I am reluctant to change the wording of the amendement, given that the whole point is a) to say that a GR is unwelcome, and b) to reduce as much as possible the “attack surface” on the voted text in case some people want to use it to continue arguing after the vote. The discussion in this GR falls short of concrete examples of a) what is wrong in Jessie, b) how it should be corrected and c), why would a GR be needed. The burden of the proof is on the side that asks for a GR, not the reverse. If there is not concrete problem to solve, there should be no vote. I consider this GR strongly anti-democratic and anti-doocratic. The different amendements require digging in long, noisy threads to assess what is the common understanding of them (and thanks Lucas for your summary, but it did not help me to have a clear picture of what would be the most likely concrete consequence (that is, not “what the rules are”, but “how the system runs“) of voting each amendement). This makes the GR anti-democratic since the safest choice becomes to vote by the names of who proposed and seconded an amendement rather than by the contents of the amendement itself. And it is anti-doocratic since it lays general principles for the Jessie + 1 release without even giving a chance for the people who will do the work to prepare this release in a brilliant way that does not require the project to constrain their choices. [I can not beleive I spent an hour writing this short text; I hope it is my last email related to this GR.] Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20141021143145.ga21...@falafel.plessy.net
[Sorry Neil] Wording modification of the The ???no GR, please??? amendement.
Le Tue, Oct 21, 2014 at 08:13:52PM +0200, Holger Levsen a écrit : On Dienstag, 21. Oktober 2014, Sam Hartman wrote: my response is so what? People are doing their jobs, let's not get in their way. I'd rather this amendment not push people away simply because they disagree over whether all the questions have been answered. I agree. I've also been thinking whether I find the distinction pointed out by Lucas to be so important as to offer another amendment if Charly doesnt want to change his... I'd definitly prefer to have this statement once on the ballot than twice. So, Charles? Indeed, you are right: by definition, not all questions have been answered. The existing wording of the amendement is therefore logically inconsistent. I propose the following replacement as per article A.1.5 of our Contitution. The Debian project asks its members to be considerate when proposing General Resolutions, as the GR process may be disruptive regardless of the outcome of the vote. Regarding the subject of this ballot, the Project affirms that the procedures for decision making and conflict resolution are working adequately and thus a General Resolution is not required. I avoided terms like “premature” and “at this time”, since they leave a bit of an impression that a GR will definitely be needed, but only later. This is one of the main resons for my initial reluctance to accept Antony's and Lucas' comments. If further changes are needed, please suggest a full replacement: I am reaching the limits of my writing skills in English (an again: a GR that requires near-native fluency in English because the consequence of the vote will strongly depend on how the text is interpreted is anti-democratic in Debian). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan signature.asc Description: Digital signature
Re: [Call for seconds] The “no GR, please“ amendement.
Le Sun, Oct 19, 2014 at 05:01:02PM +0200, Lucas Nussbaum a écrit : --- The Debian project asks its members to be considerate when proposing General Resolutions, as the GR process may be disruptive regardless of the outcome of the vote. Regarding the subject of this ballot, the Project affirms that the question has already been resolved and thus does not require a General Resolution. --- I think that it would be very helpful to describe how the question has already been resolved. My understanding is that the various proposals add policy on something that isn't currently covered by the Debian Policy or by TC decisions. Alternatively, your resolution could state that the current de-facto policy of supporting both systemd and sysvinit (sometimes through systemd-shim) should be kept for Debian jessie, and that deciding on policy beyond jessie is premature at this point. Hi Lucas, being more precise would somehow defeat the point of stating that no GR is needed, because the way the solution would be expressed, with its imperfections, would then become binding. This said, let me clarify my understanding of the current situation. - Pepole running GNOME and desktops needing features not found in other init systems will be migrated to systemd during update. - Whether other people will be migrated or invited to migrate is in the hands of the release team, who decides which packages are part of Jessie or not. The techincal commttee has already given the general direction: we change the default init system. In my opinion, this general direction is how the “question” is resolved. Current decisions on which package depend on what, etc, stem from that decision. As of today I do not think that we need the technical comittee, the Policy or a GR to further constrain the work of the release team. Replacing the init system is a major change, and obviously some people who used expert skills to set up their system may need their expertise to upgrade it. This, also, is a logical consequence of the TC's decision, and I trust the various package maintainers that they are doing their best to make the transition as easy as possible. Regarding what is proposed, it is actually unclear. The consequence of accepting the main proposal may range anywhere between “do nothing special” and “harrass the GNOME and systemd maintainers until they quit”. I am sure that this is not Ian's goal, but I am not sure he is in position to prevent this to happen. In the case of your proposal, I appreciate your effort to cool down the situation and you are definitely in your role to do so, but if the whole point is that after voting it, nothing changes except that people stop complaining, then I would like to introduce a ballot option that focuses on that point: telling people who do not have a clear and realistic action plan (that is, no wishful thinking) to stop complaining. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20141019230628.GA4618@aqwa.igloo
[Call for seconds] The “no GR, please“ amendement.
Le Sat, Oct 18, 2014 at 05:31:28PM +0200, Matthias Urlichs a écrit : Charles Plessy: This is why I am proposing this amendement, to say: “this GR was a bad idea, please do not do it again”. I would not regard it as an amendment, but as a separate alternative option on the ballot. If I were you, I'd add another paragraph, like Regarding the subject of this ballot, the Project affirms that the question has already been resolved and thus does not require a General Resolution. and then formally ask for seconds. Thanks again for the good suggestion. Regarding the terminology, in my understanding, alternative options on the same ballot are amendments, even if they fully replace the original proposition. Anyway, whichever the name I call for seconds (or comments: if this proposed amendment is considered harmful, let me know). Here is the text: --- The Debian project asks its members to be considerate when proposing General Resolutions, as the GR process may be disruptive regardless of the outcome of the vote. Regarding the subject of this ballot, the Project affirms that the question has already been resolved and thus does not require a General Resolution. --- Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan signature.asc Description: Digital signature
Re: Proposed amendement: be more careful when proposing a GR.
Le Fri, Oct 17, 2014 at 12:37:19PM +0200, Matthias Urlichs a écrit : Charles Plessy: --- The Debian project asks its members to be more considerate when proposing General Resolutions, and in particular to take care that the proposed GR has actual chances to be accepted, considering that GRs is a disruptive process regardless the outcome of the vote. --- Slightly reworded: The Debian project asks its members to be considerate when proposing General Resolutions, as the GR process may be disruptive regardless of the outcome of the vote. In particular, a proposed GR should have an actual chance of being accepted. Thanks Matthias, for the rewording. Are there people willing to second this reworded version ? Whichever the result of this GR, the people who did not want it will lose: at the very minimum, we lose our time. And to reject the initial proposal, we will have to either vote for “further discussion” while not being interested in disussing further, or for a status quo proposal that can be twisted and misused if it is not worded perfectly. This is why I am proposing this amendement, to say: “this GR was a bad idea, please do not do it again”. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan signature.asc Description: Digital signature
Proposed amendement: be more careful when proposing a GR.
Le Thu, Oct 16, 2014 at 04:05:41PM +0100, Ian Jackson a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I wish to propose the following general resolution, and hereby call for seconds. This GR resolution proposal is identical to that proposed by Matthew Vernon in March: https://lists.debian.org/debian-vote/2014/03/msg0.html Hi Ian, the seconders, and everybody, I think that this GR does nothing but demotivating those doing the work. It may give a warm feeling to those who oppose the curent direction taken for Jessie, because they can satisfy themselves that they tried everything they could, but what Debian gains with this ? Nobody prepared a workable alternative, and opposing a change does not go automatically with the capacity of building the alternative. In the end, I think that this GR is just a show. I do not see it winning, nor even approaching majority. And I think that GRs should not be proposed if they have no serious chances to win, given that each GR costs us time, energy, division and bitternes (and I know what I am talking about). Therefore, I propose the following amendement. Please do not take it personnaly. --- The Debian project asks its members to be more considerate when proposing General Resolutions, and in particular to take care that the proposed GR has actual chances to be accepted, considering that GRs is a disruptive process regardless the outcome of the vote. --- Enhancements of the wording are welcome. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan signature.asc Description: Digital signature
Re: ``Disclaimer'' field to document non-free-ness reasons [ Was: non-free? ]
Le Thu, Mar 27, 2014 at 10:48:48PM +0900, Stefano Zacchiroli a écrit : Questions for my -policy friends: can I conclude from the above that the Disclaimer field is to be used _only_ for contrib/non-free packages, and only to explain the reason of their (transitive) non-free-ness? Or is there a risk of overloading it for other reasons? (The current text implies it is not, but the name is a bit generic, and I prefer safe over sorry.) Hi Stefano, this use was my intent in 2008 when I added this field, following the release of version 3.8.0.0 of our Policy, that closed bug #65577 asking that “copyright should include notice if a package is not a part of Debian distribution”. https://wiki.debian.org/Proposals/CopyrightFormat?action=diffrev1=183rev2=184 I do not remember if I wanted the Disclaimer field to be exclusively used for statements that packages are not part of the Debian distribution. In any case, a quick inspection of the Debian copyright files in the “packages-metadata” repository show that the field is also being used for other purposes. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20140328001251.ga21...@falafel.plessy.net
Question on DPL delegations.
Le Tue, Mar 25, 2014 at 05:44:55PM +0100, Lucas Nussbaum a écrit : Internally, we would need to adjust, but I'm quite sure that we would manage. Actually, the lack of a DPL might make everybody feel more enabled/empowered to solve problems that are usually deferred to the DPL, which could be a good thing. Hi Lucas and Neil, without DPL, there would be no DPL delegations. I have a question for you related to delegations. When a delegate is completely inactive as a delegate, do you think that his delegation should be renewed ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20140325223112.ga31...@falafel.plessy.net
Re: Proposal - preserve freedom of choice of init systems
Hello everybody, since it does not seem like we are going to vote, could you find another place for that discussion ? (Of course, please avoid debian-devel and debian-project; thanks in advance) Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20140305124949.ga1...@falafel.plessy.net
Re: [Proposal] GR: Selecting the default init system for Debian
Le Mon, Jan 27, 2014 at 08:39:52PM +0100, Guillem Jover a écrit : This is the revised draft GR proposal (please see below); I'm looking for sponsors now. Hi Guillem, if the result of the current TC vote is « further discussion », then I will second your GR. In the meantime, it is probably better to focus our thoughts on something else; it is only a matter of days now. In the past, I have been alternatively on the side of proposing an impopular GR, and of strongly criticising another GR for its uselessness. My personal conclusion is that in doubt, a GR could contain an « rotten tomatoes » option such as: « this GR should not have been proposed », perhaps with a better wording. Can you consider that addition ? I will take my share of tomatoes if it turns out that the Project finds the option useful ! Have a nice day, -- Charles -- 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/20140127224126.gb8...@falafel.plessy.net
Re: GR: Selecting the default init system for Debian
Le Thu, Jan 23, 2014 at 04:14:41AM +0100, Wouter Verhelst a écrit : On Thu, Jan 23, 2014 at 09:58:14AM +0900, Charles Plessy wrote: In that case, I think that the project should decide via using this or that system (“vote with the feet”). For the packages where init scripts are a limitation, just depend on systemd, upstart, openrc, or combinations of them, and if and only if it is not possible to install Debian because pairs of core packages depend on different single init systems, let's vote. So, let me get this straight. Hi Wouter, OK, let's be straight :) You're saying let's do nothing until the entire system breaks because of a component that nobody really cares about, so that we can _then_ try to start a procedure which will take weeks (if not months) to maybe unbreak it, leaving the system in an utterly broken state in the meantime? What I am saying is: Let's allow the Debian system to evolve freely: the result will not be breakage, but systemd as a de facto default. If some parts of the system become mutually exclusive, I do not see it as problematic. We do not support the co-installation of some mail or FTP servers packages even though in theory one can configure them to listen on different ports; if tomorrow one desktop manager depends on upstart and another on systemd, then the solution is to call this unsupported as well. I would also argue the same if it were web browsers. I would call a system broken if it would not be possible to do anything useful with any of the init systems. I do not see how this could happen. First, these init systems are developed and tested on computers that run them, such as Fedora, Ubuntu and Gentoo, which shows that there is no critical missing piece in one or the other system in the context where they are intended for. Second, at least systemd runs fine on Debian currently, and to my knowledge, there are no core components that are likely to drop systemd support in the near future. Then, there is the fear that because systemd or upstart is much easier to support than our current init system, the non-Linux architectures that can not run them will dissapear because init scripts will be dropped massively. To me it is a total overstatement. What is at stakes is whether these ports will benefit as much as before from the work on mainstream systems such as Linux on amd64. The answer with is “no”, unless we enforce a default with this goal in mind, that will cost to others what it gains to the non-Linux architectures. But that “no” does not make these projects impossible. At worse, it will force them to focus on their userbase instead of working on total coverage of the Debian package supermaket, and I think is would actually be a good change (please do not waste your time sending patches to leaf packages until you know that somebody is actually planning to use them on your port). Lastly, there is the political part. Should we boycott systemd or upstart ? Should we make choices that in practice mean to show the door to our GNOME team ? Should we push even more our contributors to participate to the porting on specialised architectures ? Let's releive the technical comittee from the pressure to step in that field. The best reaction to these questions is to ignore them. So definitely, thanks Steve and the sysinit maintainers for making transition between init systems easier; with this I do not think that we need a decision on a default system anymore. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20140125112035.gl24...@falafel.plessy.net
Re: GR: Selecting the default init system for Debian
Le Sun, Jan 19, 2014 at 01:01:44AM +0100, Guillem Jover a écrit : I think that forcing a decision through the TC at this time was very premature and inappropriate, because I don't think enough effort had been made to reach consensus (failing §6.3(6)) Hi Guillem, I agree that calling the TC was premature. We have a default init system that has the Essential flag, and it is impossible to switch to alternatives without going through a very strong warning. In my understanding, to have GNOME 3.10 in Debian, we need to work around this difficulty. As a consequence, this would pull systemd on such a large number of systems, but as long as GNOME needs to explicitely depend on it, it is still not the default. I have not read GNOME or systemd packagers asking to the maintainers of packages containing init scripts to drop support for our current default system. The Debian way of doing things is that if a systemd service file is missing, a patch should be sent. If the TC choses a new default that is not systemd, the situation of GNOME does not change: it will still need a mechanism to pull systemd and replace the default. But at the time the TC was called, I was not under the impression that the GNOME or systemd maintainers have asked for a decision, and I very much agree with that: first, one has to show in Testing a system where GNOME and systemd work well. In that sense, the call to the TC was premature: we should remove obstacles for change, and only top-down decide when some ways are incompatible in a way that is affecting a large number of users. If one day it is not possible to have Desktop manager A and Desktop manager B installed on the same machine, the solution may be simply to call this unsupported unless there is a significant demand for this feature. Perhaps the way out is to solve the technical problem regarding the Essential flag so that it is easier to install systemd, upstart or openrc, and defer a decision untill the call for change comes from enough maintainers of init scripts saying that they want to stop supporting it. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20140122235808.gc12...@falafel.plessy.net
Re: GR: Selecting the default init system for Debian
Le Wed, Jan 22, 2014 at 04:26:16PM -0800, Steve Langasek a écrit : On Thu, Jan 23, 2014 at 08:58:08AM +0900, Charles Plessy wrote: We have a default init system that has the Essential flag, and it is impossible to switch to alternatives without going through a very strong warning. Factually incorrect. The sysvinit package in unstable has been fixed to depend on sysvinit-core | upstart | systemd-sysv, allowing users to switch between init systems without removing an essential package. Thanks for the clarification. An earlier message in this thread gave me the impression that it still had been the case (that I went through when installing systemd on my machines), but indeed I was wrong. In that case, I think that the project should decide via using this or that system (“vote with the feet”). For the packages where init scripts are a limitation, just depend on systemd, upstart, openrc, or combinations of them, and if and only if it is not possible to install Debian because pairs of core packages depend on different single init systems, let's vote. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20140123005814.gd12...@falafel.plessy.net
[all candidates] What to do with debian-private ?
Le Thu, Mar 28, 2013 at 03:35:40PM -0700, Don Armstrong a écrit : -private is notified so DDs are aware. How is the state of -private those days ? When I unsubscribed, it was still mixing informations that are really private, like Alice takes holidays in Honolulu, some that may be private by accident, like Bob wants to package libfoo-perl, and some that are irrelevant, like Claudius likes pasta well cooked, Donna does not like discussions about pasta, and Eros thinks that one should not be criticised for discussing about pasta on -private. I found it very tiring to have to permanently remember to never talk about a lot of things that should never have been private in the first place. If this has not changed, is that something that the DPL candidates would like to tackle ? (Bonus question to the DPL candidates: are you subscribed to debian-private ?) Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20130330013408.ge23...@falafel.plessy.net
Re: [all candidates] delegation
Le Thu, Mar 28, 2013 at 08:46:28PM -0600, Moray Allan a écrit : Stepping down should be seen as a sign of accomplishment. It should not be seen as losing the ability to provide advice. It should be seen as an opportunity for someone to use their skills in other aspects of the project, to produce more great things. Separately but importantly, it should be seen as a healthy thing for the project. Hi Moray, what you wrote here presents the end of a delegation as a final point. However, I was very interested by your use of rotation, which I was understanding as a faster turnover where the responsibility of the delegation is passed through developers according to the pool of compentent people. Taking the Debian Policy Editors as example, I would not mind being replaced in October 2013, and (provided that I still have the free time), I would not mind serving again from October 2104. All of this without reducing my contribution in terms of patches, but only rotating who is responsible for committing them. So can you clarify how proactive you intend to be in terms of promoting rotation for the existing delegations ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20130329035424.ga2...@falafel.plessy.net
Re: To all candidates: which way out of the project ?
Le Wed, Mar 20, 2013 at 10:15:32AM +0100, Gergely Nagy a écrit : Do you see a particular problem, or shortcoming, perhaps, that you'd like to see solved? Hi all, the problem I was trying to solve was to find more differences between the candidates :) For instance, one of you might have answered that he is really enthousiastic about yearly pings, or that he is very concerned about dormant accounts, or anything that I did not expect, etc. Thanks for your anwers, and have a nice week-end, -- Charles -- 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/20130323003226.gb30...@falafel.plessy.net
Re: [all candidates] Return to the desert island (cont.)
Hi all, I propose that either the discussion is reshaped to be more interactive with the candidates, or it is moved to another channel where a broader participation is expected. Cheers, -- Charles -- 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/20130321035944.ga20...@falafel.plessy.net
To all candidates: which way out of the project ?
Hi, I did not manage to formulate a better subject... the question is about what should be the usual way to end our formal membership in the Debian project. In Debian, we stay member until we die or quit (or very exceptionally, are expelled). The consequence is that it is hard to evaluate how much active members we have. It may also create more crispations about giving membership. We often discussed about how to become a member, but more rarely about the other side of it. I would be interested to read your opinion, especially on the implications that the current practice, or possible changes, have for the project as a whole. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20130320022216.gb30...@falafel.plessy.net
Re: Your opinion on Debian Maintainer status
Le Mon, Mar 18, 2013 at 10:32:09AM +0100, Stefano Zacchiroli a écrit : On Mon, Mar 18, 2013 at 09:56:16AM +0100, Lucas Nussbaum wrote: Also, the wiki has pages for http://wiki.debian.org/DebianDeveloper but also for http://wiki.debian.org/DebianProjectMember that says: Debian Developers are Debian Project Member with uploading rights As observed in the past, the Debian Constitution treats members of the project and Debian Developers as synonyms. So, no matter DAM/FD opinion, the claims on those wiki are not correct and should be amended. Thanks for pointing this out. Hi, Perhaps the candidates can comment on the fact that this already been raised last year, and if they have something to propose in order to make discussions more productive on debian-devel. http://lists.debian.org/debian-devel/2012/07/msg00716.html (On my side I am probably guiltly of not insisting for deleting these pages if nobody claims responsibility for what is written in). Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20130318094516.ga30...@falafel.plessy.net
Re: to Moray: encourage teams to take interns
Le Mon, Mar 11, 2013 at 08:07:40PM +0300, Moray Allan a écrit : Nevertheless, I think it would be useful for us to have some wider kind of internship scheme, for the huge proportion of Debian activity that definitely will not fit under the current GSoC rules. Hi Moray, I have a question: could you comment on the differences, complementarity, or overlap between such an internship and the NM process, which already has extensive questions about packaging. My personal experience is that when I went through the NM process I learned a lot through the exchanges with my AM, to the point that I felt it close to be a kind of internship sheme... Lucas and Gergely, you are of course free to comment if you wish. Cheers, -- Charles -- 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/20130312064538.ga12...@falafel.plessy.net
Re: General Resolution: Diversity statement
Le Tue, May 08, 2012 at 05:57:40PM -0400, Michael Gilbert a écrit : Q: What will be the procedure for maintaining/updating the statement, once voted? A: The gist of the statement will be fixed by the GR. But in order to avoid needing a vote for every minor tweak, language improvements can be applied by the -www team as for other parts of www.d.o and more substantial changes, that do not change the spirit, can be discussed on -project. Given that this statement is absent in the actual GR text to be voting on, are voters to assume it will or will not have any bearing on the outcome of the vote? Personally, I think it should not; although I'm sure opinions will vary. Given that, I don't think its possible to say one way or another. So, in order to have a definitive conclusion on this matter, shouldn't it be included in the actual GR text, or as an alternative, or as an amendment? Hi all, I hope that our constitution has the answer to that question. If a GR needed self-locking dispositions, that would go against the idea of having a constitution at all. My personal opinion is that for things that should not be changed apart with a GR, the Constitution offers the status of Foundation Document. So if the diversity statement is not a foundation document, I do not see what would forbid to change it after the GR. One problem is that the defintion of position statements about issues of the day (section 4.1.5) is not clear. Much of the driving force for this GR to be voted is its ceremonial aspect, otherwise we would be also voting on Debian's Posiiton on Software Patents, and would be digging our past decistions to see if in retrospect they need a GR as well (I am not advocating that). If a position statement is more somthing like official press releases than a law, then there would be no problem changing the diversity statement as long as it is not in a way that suggests that the updated version is the one voted in 2012. Perhaps native speakers, experienced members, or our Secretary can clarify what position statements about issues of the day means, and what is the consequence of having issues of the day limiting position statements. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20120508222110.gb32...@falafel.plessy.net
Question to all candidates: In eight years...
Dear candidates, this is the echo of a question asked two years ago in the 2010 campaign. http://lists.debian.org/debian-vote/2010/03/msg00057.html In addition, do you see major changes happening in the recent or next years, and how do you think Debian should react to them ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20120320102755.ga12...@falafel.plessy.net
Debian's trademarks and logos, and their terms of use.
Dear Wouter, Gergely and Stefano, one of the conditions for a work to be considered free is to allow others to use it without making contribution back to the original authors (even if we whish everybody would do when they can). In the non-free section of our archive, we therefore have software where the authors reserve commercial use for themselves. In contrast with what we require for the software we distribute, we are forbidding to use some of our logos for profit. While there are some clear differences between software and carriers of visual identity, I feel that there is a strong mismatch between what we ask and what we give, if we reduce a software on one side, and Debian's reputation on the other side, to the fruit of the efforts of their makers. Said differently, I see a contradiction between forbidding people making money by printing our name on T-shirts, and requiring that all the software we distribute can be used for profit. I would like to know your position or vision on our trademarks and logos, and, if you indend to work on that question as a DPL, what would be the key points of your action. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20120314004701.ga29...@falafel.plessy.net
Understaffed teams.
Dear Stefano, I read in your platform that you would like to have core teams of “at least three members plus assistants”. However this does not take activity into account. How will you manage with inactive core team members ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan Disclaimer: I am not a native speaker. I have spent more than 5 minutes writing this question and some words may be better, but I am unable to find them. Please be patient. I am not trying to attack or hurt anybody. -- 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/20110322232710.gc21...@merveille.plessy.net
Re: Naming of non-uploading DDs (Was: GR: welcome non-packaging contributors as Debian project members)
Le Thu, Sep 16, 2010 at 02:03:01PM +0100, Matthew Johnson a écrit : OTOH, if we pass a GR that looks like we'll give them upload rights (because it just says they are DDs) and then they aren't given upload rights some people might feel upset that they voted for it. Just because it's not required doesn't mean it might not be a good idea to include it. Stefano's DPL platform is actually quite clear on the subject: We need to generalize the lessons learned from the DM process. We have a lot of potential valuable contributors out there. They just need better documentation about how to join. They simply demand something in exchange, to be proud of, that acknowledges their efforts. I do not have preconceptions on the different ways of achieving this (e.g. ACLs vs linearly increasing privileges), but we need to go in that direction. In doing so, we should also relax our implicit assumptions that only technical abilities matter in Debian. The best operating system is mainly, not only, made of software; it is also made of translations, graphics, musics, etc. I will push for more gradual and rewarding access paths to Debian. So if we vote for a GR that do not give a direction, it will be unsurprising that DAM and FD will implement a ‘gradual’ access to our facilities. But the important thing is that it will not be asked by the GR. After seeing the results of this choice, it will always be possible to change the procedure, especially if a later DPL is elected with a platform that goes more towards an equal access for all DDs. [Of course, I noticed that the GR is actually carefully worded to not decide anything, but only to invite. Still, I think that if it contains an invitation to not give upload access to DDs who do not maintain packages, it will be difficult ignore it.] I would love to vote for an amendement that invites DAM and FD to give a normal upload access to all DDs, but they are free to decline the invitation (and it is a good thing). I think that we need to compromise and move on, and I propose to do so by avoiding a wording that would make it difficult to change our choice on this subject later. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100916135151.ga23...@merveille.plessy.net
Re: GR: welcome non-packaging contributors as Debian project members
Le Tue, Sep 14, 2010 mat 06:29:24PM -0700, Russ Allbery a écrit : Charles Plessy ple...@debian.org writes: after seeing the torrent of seconds, I am still puzzled if this GR is a progress or a regression: is the take home message that Debian should be more open, or that some members must not have upload rights ? When a member does not have upload rights, is it for the principle of least needed priviledge, which suggests that getting that prividedge may be granted automaticaly later with the need, or because that member is not trusted to be able to upload correctly ? Well, if one isn't interested in upload rights, there's no need for one to qualify on upload rights during NM, which implies omitting or at least much abbreviating the Tasks and Skills part of NM. But if we want to maintain the policy that anyone with general upload rights complete Tasks and Skills for package uploads, we wouldn't want to extend those rights later without having the person go through NM. I think that this is where our point of view differ the most. I think that somebody who was accepted as a member, because he showed enough reliability in his work, respect for our procedures and commitment in his contributions, does not need to qualify again to start uploading packages when his contribution eventually evolves in that direction. We are proud to be a do-o-cracy. I think that we can let our members to demonstrate their capacities by giving them the opportunity of doing the things right, instead of passing certificates. If we trust somebody to manage correctly his SSH and GPG keys and prevent from bad people stealing his identity and loging in our machines with bad intentions, then I think that we must trust that person to not do rogue NMUs nor upload to NEW packages that they do not have the capacity to maintain. More in general, I think that the principle of least priviledge is best applied when a large majority do not need them (like driving trucks and airplanes, or logging in some machines at the core of our infrastructure), but is not much benefical when it is about managing a minority. But the core of my disagreement is not about priviledge management, which already takes place for other operations than upload, but classifying DDs through the passage of certificates, since in my understanting a DC will be a DD for whom it will be remembered that TC was not passed, and who will not be able to upload until he passes that test. I have to say that I am also worried that this is just the beginning of a more comprehensive categorization of the roles within Debian. The application managers and the front desk are doing great work in managing the request to join our project, but I object extending their role to manage the access of the DDs to the components of our architecture. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100915084303.ga30...@merveille.plessy.net
Re: Naming of non-uploading DDs (Was: GR: welcome non-packaging contributors as Debian project members)
Le Wed, Sep 15, 2010 at 09:00:32PM +0900, Stefano Zacchiroli a écrit : The Debian project therefore invites the Debian Account Managers to: * Endorse the idea that contributors of non-packaging work might become Debian Developers, albeit without upload access to the Debian archive. * Establish procedures to evaluate and accept contributors of non-packaging work as Debian Developers. * Initiate the appropriate technical measures to enable contributors of non-packaging work, which get accepted as Debian Developers, to participate in Debian decision making and to access Debian infrastructure. It seems to me that, if “albeit without upload access to the Debian archive” were removed, it would not close the possibility for the people in charge to restrict upload capacities of developers who do not need them (do-o-cracy), while at the same time it would make the GR more neutral, focusing it on acceptance of new members, without suggesting restriction and therefore difference of status. Would such a change be a happy end for everybody ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100915121600.gd30...@merveille.plessy.net
Re: Naming of non-uploading DDs (Was: GR: welcome non-packaging contributors as Debian project members)
Le Wed, Sep 15, 2010 at 10:01:47PM +0900, Stefano Zacchiroli a écrit : On Wed, Sep 15, 2010 at 09:16:00PM +0900, Charles Plessy wrote: It seems to me that, if “albeit without upload access to the Debian archive” were removed, it would not close the possibility for the people in charge to difference of status. snip Would such a change be a happy end for everybody ? Sorry, but I really can't accept that as a simple editorial change to the text I've proposed. To go that way, please check my discussion points in http://lists.debian.org/debian-vote/2010/09/msg00052.html. In case there is a doubt: my intention is not to ask Stefano if he thinks that the proposed change is good for everybody, but it is to ask everybody who may care, in particular the Debian application managers and front desk, if the proposed change would be welcome… Good night, -- Charles -- 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/20100915151140.gc1...@merveille.plessy.net
Re: Naming of non-uploading DDs (Was: GR: welcome non-packaging contributors as Debian project members)
Le Wed, Sep 15, 2010 at 10:02:34PM +0200, Bernd Zeimetz a écrit : On 09/15/2010 02:16 PM, Charles Plessy wrote: Le Wed, Sep 15, 2010 at 09:00:32PM +0900, Stefano Zacchiroli a écrit : The Debian project therefore invites the Debian Account Managers to: * Endorse the idea that contributors of non-packaging work might become Debian Developers, albeit without upload access to the Debian archive. * Establish procedures to evaluate and accept contributors of non-packaging work as Debian Developers. * Initiate the appropriate technical measures to enable contributors of non-packaging work, which get accepted as Debian Developers, to participate in Debian decision making and to access Debian infrastructure. It seems to me that, if “albeit without upload access to the Debian archive” were removed, it would not close the possibility for the people in charge to restrict upload capacities of developers who do not need them (do-o-cracy), while at the same time it would make the GR more neutral, focusing it on acceptance of new members, without suggesting restriction and therefore difference of status. I don't think we should open a second way to get upload rights to the archive, so I would *not* want to remove that part. So do you think that if “albeit without upload access to the Debian archive” is not present, the GR will prevent you from restricting upload access to the archive for the DDs who did not pass TS? I am looking for a formulation that invites you to do what you want, without giving a preference for or against the restriction of upload rights. Cheers, -- Charles -- 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/20100916055807.gb22...@merveille.plessy.net
Re: GR: welcome non-packaging contributors as Debian project members
Le Tue, Sep 14, 2010 at 05:53:46PM +0900, Stefano Zacchiroli a écrit : Of all those topics, one topic *might* have consensus already: accepting as DDs contributors which have contributed a lot to Debian doing non-packaging work, which intend to continue doing so, and which are ready to uphold our Foundation Documents. Hi Stefano, I agree with the above, accepting as DDs contributors who do not maintain packages, but your proposal is different: it establishes a new class of project members, who differ by not having upload rights. I suppose that the goal is to avoid disruptive NMUs and damage to our infrastructure in case their GPG key is compromised. But do you think that this is more likely to happen with developers who do not maintain packages, compared with developers who do? I wonder why not simply inviting the Debian Account Managers to accept the long term contributors as DDs, even if they to not maintain packages? Would an amendement be welcome? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100914095213.ga24...@merveille.plessy.net
Re: GR: welcome non-packaging contributors as Debian project members
Le Tue, Sep 14, 2010 at 06:56:01PM +0200, Lucas Nussbaum a écrit : My own preference is [B] [A] [original GR proposal]. But I'd like to hear some other opinions before working on a draft amendment for either [A] or [B]. Hi Lucas and everybody, after seeing the torrent of seconds, I am still puzzled if this GR is a progress or a regression: is the take home message that Debian should be more open, or that some members must not have upload rights ? When a member does not have upload rights, is it for the principle of least needed priviledge, which suggests that getting that prividedge may be granted automaticaly later with the need, or because that member is not trusted to be able to upload correctly ? I would welcome clarifications in the GR text. Alternatively, I am willing to second amendements like the ones you propose, or to help with the drafting if you need. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100915011705.gb29...@merveille.plessy.net
Re: DPL2010 results
Le Fri, Apr 16, 2010 at 02:09:31AM +0200, Kurt Roeckx a écrit : The unofficial results are at: http://master.debian.org/~secretary/leader2010/ The winner is Stefano Zacchiroli. Dear all, I would like of course to congratulate Stefano, and wish him a lot of fun. Stefano has obviously a lot of energy, but nevertheless let's do our best that it is never wasted! I would like to thank the secretaries and the other candidates as well, for the time they gave to this election. The number of unique voters is in sharp increase this year, and I have no doubt that their efforts participated to this. Of course, the people behind the NM queue also desserve credit for the new blood that they let join our Project this year! Have a nice week-end, everybody ! -- Charles -- 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/20100416012756.ga32...@kunpuu.plessy.org
Re: Questions for all candidates: decentralization of power
Le Thu, Apr 01, 2010 at 11:53:47AM -0400, Mike O'Connor a écrit : It doesn't take long processing NEW to realize that many DDs cannot be trusted to make sure that all of the code they are uploading is legally redistributable. I also think that we need to review the NEW uploads. But this is not what I discuss here. I propose to let all DDs look what is in the NEW queue. (This would of course help to review the NEW uploads). The problem is also one of accountability. If the DD screws up and eventually an ftp-master or a mirror owner or DPL or SPI or someone else is the one getting sued, can the person getting sued hold the DD accountable? “Screwing up” here would be for a DD to log in on the ftpmaster mirror, take a package from the NEW queue, and redistribute it in parallel to the Debian archive. I think that the claim that some people can be sued if some DD screwed up is vague, and is really difficult to discuss factually. I think that if the NEW queue in the ftp-master mirror is readable for all the DDs, there is no risk for the DPL, his delegates, or the sponsor of the provider of the ftp-master mirror machine and connectivity to be sued. Have a nice day, -- Charles -- 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/20100401162702.ga19...@kunpuu.plessy.org
Re: Question to all Candidates: we want more, aren't we?
Le Thu, Apr 01, 2010 at 09:57:38AM +0200, Frank Lin PIAT a écrit : Debian project raise it's expectation every year: higher quality, more package, more architectures, more Desktops, etc... (cool). How do we face the challenge to do more every year? What would you do about it, as a DPL? Hi Frank, I think that we should open Debian's door wider, and reduce restrictions on the operations on our infrastructures, so that the growth is sustainable. Cheers, -- Charles -- 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/20100401163402.gb19...@kunpuu.plessy.org
Re: Question for the other candidates: supermajority.
Le Thu, Mar 25, 2010 at 05:38:09PM +0100, Stefano Zacchiroli a écrit : I don't like the underlying intuition that this entails, namely that the GR proposer is somehow different from the other people which contribute to the ballot preparation (e.g. seconders and proposers of the initial and subsequent amendments). Hi Stefano, the core of my idea is that somebody should feel responsible for the success of a GR. Votes are big investments; in our countries they cost a lot of money and in Debian the cost a lot of energy that is not spent on development. Being able to control the contents of the GR gives the possiblity to really influence on the outcome, but since NOTA is always an option, I think that a misuse of such a responsibility would lead to failure and the vote of a competing GR, and not in an artificial advantage. Cheers, -- Charles -- 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/20100401164045.gc19...@kunpuu.plessy.org
Thanks to everybody for this campaign.
Dear all, this campaign has been much more intensive than I thought. I would like to thank everybody for their questions, and the other candidates for their answers. I had difficulties to keep up and regret that I could not discuss ideas deeper with the other candidates. I am also sorry that I left some questions unanswered, even in the case where I promised in private that I would give a proper answer later... After this campaign, I have the feeling that among the four candidates, my approach is the most institutional and the least inspirational. I will not pretend that it is a solution that would be good every year. But I think that for next year, action about membership and delegations, and strategical discussions about how we distribute our work would be very useful. I invite you to vote for me if you share this feeling. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100401165813.gd19...@kunpuu.plessy.org
Re: Question for DD candidates: The race against NOTA
Le Tue, Mar 16, 2010 at 10:32:22PM -0600, Gunnar Wolf a écrit : What would be different if there was no leader? Where would the project lose more? Would it gain in some aspect? Hello Gunnar, Biology shows that complex systems often evolved “leaders”, even when they are selected or take their actions randomly. In Debian as well, I think that a DPL or an equivalent function is necessary, not as a position of power, an official face or a model to follow, but as a piece of the machine that makes a coordinated project, as opposed to a fruitful but ephemeral collaboration of independant entities. Have a nice day, -- Charles -- 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/20100331153540.ga15...@kunpuu.plessy.org
Re: Question to the candidates
Le Tue, Mar 23, 2010 at 11:49:53PM -0700, Steve Langasek a écrit : As a developer, how do you embody the spirit and culture that has made Debian a great operating system? If elected DPL, how will you inspire the same in others? Hi Steve, we have to inspire each other and the DPL does not make exception. But if the spirit and culture that has made Debian a great operating system is universality, one single individual can not impersonate every facets. Nevertheless, in addition to universality, I think that one major element of Debian's culture is to aim at excellence, and that a DPL should be careful of being clear and accurate in his work and communication. I will do my best to inspire others by doing what I say and saying what I do, staying neutral and humble, and not engage into or provoke conflicts. Have a nice day, -- Charles -- 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/20100331155255.gb15...@kunpuu.plessy.org
Re: Question to all candidates: DPL's role in important package maintenance
Le Sat, Mar 27, 2010 at 06:27:00PM -0500, Kumar Appaiah a écrit : My question to you is, do you envision a role for the DPL in fixing such inadequate maintenance of important packages. Hello Kumar, for the moment, you have taken the way of the Technical Comitee, and this does not require the intervention of the DPL. Asking the TC to solve a disagreement between two parties should be the occasion to write down the problem in a clear and concise way. In the case of Python, I think that it is really problematic that the maintainer did not give his point of view in public yet; I hope that it is only a question of time. Without interfering with the TC, as a DPL I would ask to the python's maintainer to explain himself on our mailing lists (this can be as simple as CCing the summary he has to send to the TC), and in return would make sure that he will not him regret this concession, by discuss in preliminary with the listmasters about the possiblity of limiting or delaying messages in case of a momentary lapse of self-control (the big red button that I proposed in another email). More in general, the DPL could be proactive. When a package or a service becomes very popular and interdependant with the rest, I would contact the responsible person or team and propose them to become more formal via a DPL delegation. Have a nice day, -- Charles -- 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/20100401002325.ga16...@kunpuu.plessy.org
Re: Questions for all candidates: decentralization of power
Le Wed, Mar 31, 2010 at 12:00:05PM -0400, Mike O'Connor a écrit : You do get to choose the priority and section which your packages belong to, though the ftp team can override your choice. When we do override your choice, you get an email inviting discussion about it. I can't think of any instance where the ftp team and maintainers haven't been able to come to an agreement about where the packages belong. The alternative option, where DDs are given write access to the dak database doesn't seem worth the security issues for the small benefit(?) of avoiding having this discussion with the ftp team. Inspecting new packages which haven't cleared NEW has potential legal problems. We don't want to be in the position where we are distributing software that might not be legal for us to distribute. Our trend has been to increase the amount of info about the packages we make available on http://ftp-master.debian.org/new.html (currently down), but we have to stop short of potentially illegally distributing software. For people that want to help with the process of auditing packages in NEW, The ftp team is looking for new members, our most recent solicitation being here: http://lists.debian.org/debian-devel-announce/2010/03/msg3.html Hi Mike, you give three interesting examples on how the FTP team is isolating itself. 1) By a combination of (self-appointed?) authority and technical design, the package section splitting becomes a private tool of the FTP team. Apart from a couple of usual examples, sections are not much useful nowardays, and they are getting reimplemented in parallel through debtags, tasks, or meta-packages (just like our website is being reimplemented on wiki.d.o or alioth.d.o, etc.). I think that one of the causes is that it is not directly under the project's responsibility. What is your vision of the package sections? Where is the big picture? Why the maintainers should even care about them if everything in the design reminds them that sections are not their business, except for saving a bit of your time at the first upload? 2) We can not export software without doing some procedures, but what is the definition of an export? If it is not an export when a DD appointed by a DD delegated by the DPL logs in from outside the USA to inspect a package, then I think that the DPL or the Project can delegate all DDs equally the possibility to do this inspection and write in a NEW package's ITP bug what they think about its copyright and how it is summarised for Debian. Again, the line is currently drawn in a way that increases your workload. That is your choice. 3) The FTP team is looking for people, but you left my propositions to help with the NEW queue unanswered. Whatever your opinion on me as a person, you choice was to discard some help with no justification. In my opinion, the perimeter of the FTP team is not well defined, and has a tendency grow with self-appointed new responsibilities (like the lintian checks at upload for instance). I am not surprised that your team is running out of manpower frequently. Debian needs to trust more its maintainers, and shift from control to resilience over errors. This requires some infrastructural work, but I think that it is worth the effort. Cheers, -- Charles -- 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/20100401015807.gb16...@kunpuu.plessy.org
Re: Questions for all candidates: decentralization of power
Le Wed, Mar 31, 2010 at 11:24:50PM -0400, Mike O'Connor a écrit : The issue I was talking about had nothing to do with software crossing state lines. It had to do with violating license agreements. I'm not familiar with any procedures we must do before exporting software that you are alluding to. If we were to do what it seems like you want (correct me if I'm wrong about what you'd want). We'd have to either open up the ftp-master machine to all developers, which worries me from a security standpoint, or we'd have to be willing to distribute potentially non-redistributable software off the machine to developers, which would worry me from a legal standoint. What I would like is at least read access of the NEW queue in the mirror of ftp-master, and to my knowledge the last reason that was given to deny it is the USA crypto export rules: http://lists.debian.org/20090308040721.ga16...@dario.dodds.net If it is not an export or a license violation that a member of the FTP team inspects a package, then I do not think it is for any other member of the project. I am not proposing to give a read access to the NEW queue for any other purpose. In the past I have tried to seed a peer review process of the packages in NEW (http://wiki.debian.org/CopyrightReview), when the backlog was of hundreds of packages. I detected some problems, which were corrected before the FTP team processed the package. In one case, the maintainer even completely retracted the package. I hope that all of this saved some of your time. But I could only do this of packages that were available on mentors.d.n or in a VCS, because of the restriction on the read access to the NEW queue on the ftpmaster mirror. If because you do not trust the other DDs to respect the rules, that packages in the NEW queue must not be resdistributed before they are accepted, then yes, you have to do the work alone. If we do not think that the DDs respect the rules (http://www.debian.org/devel/dmup, in which we could add a note about NEW packages before opening up the mirror), how can we tell our users that our system is secure? Have a nice day, -- Charles -- 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/20100401044545.ga17...@kunpuu.plessy.org
Re: Question to all candidates: DPL's role in important package maintenance
Le Thu, Apr 01, 2010 at 06:47:53AM +0200, Frans Pop a écrit : Also, it has been claimed we cannot provide any information because discussions are in private [1]. Do candidates agree to that, or do they think that a DPL should make clear to parties in advance that the project will be kept informed of status and progress (but of course not of specifics). Hi Frans and everybody, Rants are better to go in private or not be sent at all, and it may be better to keep tractations private as well as long as they are speculative, to avoid fueling misunderstandings. But I think that a clear, emotion-neutral, and synthethic summary of what each party wants and what they disagree with the other is essential and has to be public. Cheers, -- Charles -- 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/20100401050137.gb17...@kunpuu.plessy.org
Re: Question for all candidates: Care of Core infrastructure
Hi all, the question of the core infrastructures is difficult and very important. Le Mon, Mar 15, 2010 at 11:30:39AM +0100, Marc Haber a écrit : Do you see the diminishing care for our Core infrastructure as a problem? Do you have any idea how do sensibilize our new blood for the fact that new packages doesn't help Debian if our Core stuff is diminishing? I know that this is not exactly within the power of the DPL, but do you think that you, as DPL, can help speeding up Core development again? Le Mon, Mar 15, 2010 at 12:52:44PM +0100, Frans Pop a écrit : Marc Haber wrote: In the last years I have seen a really disturbing development in Debian: New developers are very interested in bringing new packages into Debian, but care for our core infrastructure (dpkg, apt) has a little bit diminished. Good question and quite true. IMO it's worth adding to that: - Debian Installer development - Porting: several ports are struggling - Documentation maintenance: - website - Release Notes - various other guides Le Mon, Mar 15, 2010 at 01:36:28PM +0100, Alexander Reichle-Schmehl a écrit : ftp-team and more or less everything PR related. Le Mon, Mar 15, 2010 at 02:28:15PM +0100, Josselin Mouette a écrit : Core packages: glibc, kernel, X.org, Mozilla, KDE, GNOME… Le Tue, Mar 23, 2010 at 11:25:39PM +0100, Kurt Roeckx a écrit : I think that one of issues we have is that there is alot of work to be done by some teams, some of them even regularaly mail that they need more members, but they seem to have a hard time keeping the numbers up, burning the other team members out. What are your ideas to make sure those teams keep running? I see this as a symptom of the ‘growth crisis’ that I mention in my platform. Debian is now big enough to attract contributors who – like me – have their field of interest largely at the periphery of the system. As an enthousiastic member of a ‘Debian Pure Blend’ project, I think that it is a good thing for Debian to have this peripheral work done internally, so let's see how to help to keep an equilibrated growth, which eases contribution of all DDs to the core infrastructures. I particularly like the quote attributed to Roland, “Home is where you have to wash the dishes.”, because there is need to know to how cook to help wash dishes after the meal. And it feels good to be home. Everybody can find his own way and vary involvement according to one's own plans, but I think that we really should encourage all DDs to devote some times to common tasks. There needs to keep a good balance to be stimulating and not stigmatizing, but I think that a DPL (or other DDs) could send a general announcement asking to the other DDs what they are doing for the project and encourage them to describe their role on a personal page (like wiki.debian.org's DD portfolios). One indirect instrument to help contributors to help the core teams is a milestone-based release process like the one that was implemented for Lenny. There were regular and clear messages in the form of achieved release goals and a progressive freeze, that I found very helpful to provide a time frame in which I balanced my favorite activities with contributions of general interest, increasing the quantity general tasks as the release was getting closer. There is also a nice effort of listing teams on our wiki. In parallel to this, I would like to list and describe the DPL delegations on our website. Many core teams are structured around a DPL delegation and this list could link to pages where the teams can describe what kind of help they need (in the most simple case, the wiki team's page). Sadly, there are also teams that refuse help. In my personal experience, I proposed to help process the NEW queue or with the answer to the SPI lawyers about copyrights, and never got an answer. I will make clear on the written delegations that proposals for help must not be left unanswered, and that refusals must be justified. In my platform, I also mention that there are too many restricted operations. Checking other developers work is a very time-consuming task, and being a bottleneck is a stressful situation that leads to burnout and arguments. We need an infrastructure that is more resilient on errors, and more open access and peer review. Of course, repeated ingorance of warnings is harmful to the Project, and in the most extreme cases, a developer who does not have a responsible behaviour could be asked to refrain using some parts of our infrastructure, or quit. There are many other ways to help the core teams, with some events like the recent GNOME day, for instance. I think that they are very refreshing as they break the routine and give an extra motivation to help others. The DPL can help to establish such events if they need to be supported by some spendings (but if it becomes regular events, it would be necessary to find a sponsor). I have not answered to an important aspect of the
Re: Question to all Candidates: Who would you vote for?
Le Wed, Mar 24, 2010 at 09:09:43AM +0100, Alexander Reichle-Schmehl a écrit : Suppose that you would not run for DPL: Who would you vote and why? Hi Alexander, I would vote for Stefano, because the impressive determination he puts in his RC-bug of the day marathon suggest that he would do a lot of work as a DPL. In second, I would vote for Margarita, because I would be pleased to be proven wrong by her approach that favors inspirational over institutional actions. In third, I would vote for Wouter. Have a nice day, -- Charles -- 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/20100330235940.ga13...@kunpuu.plessy.org
Re: Question for all candidates: Release process
Le Mon, Mar 29, 2010 at 11:03:00AM +0800, Paul Wise a écrit : I find that attitude problematic. When electing a DPL we get a package deal. Some of each candidates ideas are liked by some/many, others disliked by some/many. It would be a shame to throw out good ideas with bad ones. Le Mon, Mar 29, 2010 at 09:16:41AM +0200, Joerg Jaspert a écrit : - A good idea should (unless its constitutional required, but what is?) not be bound to a DPL term. - A lost election might not mean that the ideas are all bad. (It can mean it). It might just mean they are presented wrong, or that everyone thinks they got presented wrong/at wrong time/at wrong place. Hi Joerg and Paul, you are completely right, and that why I moderated my comment by finishing it with ‘in the short term’ :) Cheers, -- Charles -- 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/20100329072751.ga4...@kunpuu.plessy.org
Re: Question for all candidates: Release process
Le Sat, Mar 27, 2010 at 01:15:47PM +0100, Stefano Zacchiroli a écrit : I don't understand what cloud computing has to do with your idea of using package priorities to release differently different sub-systems within Debian. I'm well aware that we are currently lagging behind in the race for OS for the cloud (and we should really catch up, at least in terms of visibility), but what it has to do with your idea? Hi Stefano, I think that cloud computing participates to create the demand for a Debian system that offers not only a stable release that lasts years, but also updated packages that are built or collected for being used with the stable release. A mirror containing stable, backports, and snapshots is a good first step in that direction. The problem of having all backports in one single repostitory is of course that not all packages have the same needs, which creates incoordinations or conflicts of interest. Again, I am not saying that it will be the silver bullet, but a refactored priority and sections system would allow to easily identify subsets that could have a common policy and an increased effort for coordination, or in contrary a more unsupervised mode of operation when it comes to leaf packages (trust the maintainers!). I do not pretend to offer a complete and robust solution in my platform or the emails discussed on this list. But I ask the question to the DDs: would you like to distribute your work differently? If yes, vote for me as a DPL, and will spend time and energy to help the Project go that way. (And to answer to the comment ‘you do not need to be DPL for doing this’, that is true, but if I make a bad score at this election, I will conclude that there are not many persons interested in what I propose anyway, and will save everybody's time by not discussing them further in the short term.) Cheers, -- Charles -- 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/20100329015024.gb4...@kunpuu.plessy.org
Re: Question for all candidates: Release process
Hello Bernhard and everybody, I think that the ‘RPM hell’ that you used to comment my propositions is more related to a situation when independant distributions are using the same package format, than when a distribution offers multiple repositories that obey to a policy that keeps the whole system functional. We actually enter in the era of the ‘DEB hell’ since the success of Ubuntu, with users asking support for cross-distribution package installation. In the end, it is more a communication problem than a technical problem. We should make it clearer that it is not because the packages do not carry the distribution name that they are not specific to a distribution. Perhaps a page about ‘our packaging system’ for end-users on our website? Regarding my proposal, that is internal to Debian, I do not think that it is impossible. What I propose is a way for package maintainers to signal that their package is peripheral in the Debian system, in an opt-in manner. Debian is running out of manpower, and I think that it will be useful to let know that a given package can be given a low priority for tasks. In my experience, trivial RC bugs on not-so important packages attract volunteers because it is very rewarding to close RC bugs. Also, I learnt a lot by participating to the ‘bug sprint’ organised by Josselin for Lenny, that we should not be discouraged to challenge a bug that is far beyond our technical capacities, because help like triaging and pinging the reporters is very useful and frees skilled hands that are much more useful at other tasks. So in my opinion, not all RC bugs are equal, and a better priority system would be useful to help volunteers to chose their focus. Our current priority system does not fit that task. Because of the rules about conflicts, important packages like postfix are of priority extra. By refactoring our priority system, we could make a much better usage of a priority level that really means ‘extra’ in the sense of ‘do not bother if you have more important things to do’. With a priority system improved along this direction, I think it opens the possibility to let some architectures release without the least important packages. Once I reported upstream that his scientific software was not working on Sparc. ‘I know‘, was the answer. This software, I want to bring it to the scientific communauty, and like the upstream author, I know that no researcher is seriously considering running it on Sparc for work. Why not distributing it only on amd64 until a user requests it on another architecture? Even on the other platforms where it builds, I have no clue if it works. And in my experience, the more regression tests I enable in my packages, the more I realise that they do not work on the platforms that neither upstream nor the users are using. I am very tempted to go even further and would like to distribute some packages for the stable distribution only through official backports for instance. Also, in my field, while people usually want to have the latest version to start with, they also do not want to change in the course of their analysis. I hope that the future package snapshot system will help us to satisfy this need. In conjunction with system image builders, Debian pure blends and ‘cloud computing’, it will be very powerful. Will it make the release easier? I think so, even if it is definitely not a magical wand. It transfers some responsabilities, and the work load that comes with, from the release team and the porters to the maintainers of leaf packages of low priority. I would like the Debian project to trust more its maintainers, and allow this transfer. Have a nice week-end, -- Charles -- 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/20100327061703.ga28...@kunpuu.plessy.org
Re: Question for all candidates: Release process
Le Sat, Mar 27, 2010 at 04:13:11PM +0800, Paul Wise a écrit : Does popcon not already provide a way to order packages based on importance? rc-alert has both options for sorting bugs by both local global popcon score. Hi Paul, Popcon is definitely a potent indicator, but has its flaws as well. After all, the median popcon score of Debian's ports is quite low, and we give them a lot of importance. I think that adding priorities in the equations can be useful, but after reorganising them, because for the moment, a very large majority of RC-buggy packages are of priority ‘optional’, which does not tell much. Of course, I am not campagning on that detail (the priorities), but more on the fact that we can try other release strategies, and I think that refactoring the priorities would open more possibilities. That is the main motivation for me to give this example. Should we change bts.turmzimmer.net to use that for ordering? That is really up to the bts.turmzimmer.net users. When I use it, i just go in alphabetic order and evaluate priority myself… Bapase could a nice addition, for people like me who are more on the removal mood. Cheers, -- Charles -- 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/20100327153759.ga31...@kunpuu.plessy.org
Re: Question about membership.
Le Sat, Mar 27, 2010 at 05:42:24PM -0300, Margarita Manterola a écrit : On Fri, Mar 26, 2010 at 10:02 PM, Charles Plessy ple...@debian.org wrote: * Do you need to come up with a GR to change membership procedures, or is there a different way? I will cast a GR if I think it is needed. If I am wrong, the result will be NOTA, and I will resign as DPL. You'd really resign as DPL if a certain GR that you wanted was not passed? Hi Margarita, let me clear your doubts. I think that one of the roles of the DPL is to lead debates to conclusion. I want a debate on membership, and if nobody steps up to lead it after my election (if it happens), I will lead it. If the result is a consensus, no GR will be needed. Is a result is camps so strongly opposed that chosing one option will demotivate many DDs, I will not cast a GR and prefer status quo. If the result it that the Project as a whole is hesitating between possibilities that are acceptable, I will cast a GR to make a choice and go ahead. This is what I mean by ‘if I think it is needed’. I never wrote anywhere that I will twist arms with GRs. Here is the extract of my platform about GRs: “GRs: Sometimes, lack of consensus and action does not reflect conflict or division, but simply that in a large project like Debian, which heavily relies on electronic communication, it can be difficult to get the feeling of approbation. In these cases, I think that a vote can be a very healthy process, and I will initiate GRs when the Project is blocked on choosing between directions that are all acceptable.” To answer your question about quitting, why would a DPL resign after casting a GR that results in NOTA? A GR draws energy from the project, and if badly managed, can create tensions and divisions. In particular on the membership issue, if as DPL I would cast a GR that leads to NOTA, it would mean that I failed to understand the situation, and possibly harmed the project. I think that such a failure would be so high that a demission is the correct reaction. I hope that I convinced you that it has nothing to do with which option I would vote for if such a GR would be proposed. Have a nice Sunday, -- Charles -- 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/20100328010142.ga...@kunpuu.plessy.org
Re: Question about membership.
Le Fri, Mar 26, 2010 at 02:06:44PM +0100, Bernd Zeimetz a écrit : Charles Plessy wrote: If I am elected DPL, I will re-open the discussion and lead them in a way that maximises everybody's contribution, for instance by making pauses if necessary, and by posting neutral summaries. After the discussion reaches conclusion, I will initiate a GR. When did you talk with DAM and the NM FrontDesk people about such things? Do you think it is the DPL's job to initiate GRs to change such procedures? Is a GR necessary at all or how are such things decided in Debian? When would you need a GR? Hi Bernd, I think that discussions on membership have to be held in public. If a pre-packed propsal is perpared behind the scenes and proposed to the DDs as a fait accompli, I think that it will face a strong opposition. I do not think that a DPL has the role of defining the content of a GR in such a debate. However, our constitution gives to the DPL the role of leading discussions, and to propose draft GRs. In my understanding of the constitution, the content of the GR matches the result of the discussion, not the personal opinion of the DPL. This is what I propose and nothing else. Here is the content of my platform about membership: ‘Becoming a member gives motivation, responsibility and reward. Currently one has to prove a lot to become become a DD, and I think that the level we require for new members is nearly to be able to do distribution-wide quality control and participate release operations. While it is exactly that manpower that we are critically needing, I do not think that it is in the interest of the project to be so restrictive on membership. I liked a lot an earlier proposition that any DD can nominate a new member in the project. This resembles how the DM status is working, and it is working well. Importantly, to make it easier to enter the project also makes it easier to leave it for a while. With a more appealing emeritus system, we can give motivations to DDs who are lacking time to take a break officially instead of simply becoming inactive for a long interval. And if lost membership can be recovered more easily, I think that we can also ease the conditions for cancelling inactive memberships. I will restart discussions on membership, with a vote as a goal.’ In the question I sent to the other candidates, to fuel the debate I reminded a proposition that was made and that I find interesting. I tried to make a bit of prospective, speculating that it would not be very popular, and wondering what would make it feel more secure. Taking the recent Bits from the NM process as an inspiration, which specifies that an account must be 6 month old to qualify for becoming Application Managers, I wondered if that requirement for seniority should be kept or not in a new system. Obviously, opinions about this differ. I do not have a premade conclusion about Debian's membership process, and I am not seeking to be elected for pushing one solution or the other. However, I am campaining for having the membership issue solved in the next DPL's term, and will put this priority high in my list if I am elected. Other candidates have suggested that what Debian needs is a polished version of Joerg's proposal. If as a result of my election, I lead a debate that results in a GR that does this, I will consider it as an accomplishment, whatever my personal opinon is. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100326133832.ga21...@kunpuu.plessy.org
Re: Question about membership.
* Did you or do you plan to talk to DAM/Frontdesk about membership changes? Discussion must be public from the start. DAM/Frontdesk is contribution essential. Your position will be first in the discussion's summary. * Do you need to come up with a GR to change membership procedures, or is there a different way? I will cast a GR if I think it is needed. If I am wrong, the result will be NOTA, and I will resign as DPL. -- 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/20100327010209.ga24...@kunpuu.plessy.org
Re: Standardization, large scale changes, innovations
Le Thu, Mar 25, 2010 at 11:22:36AM +0100, Raphael Hertzog a écrit : those questions are for all candidates. By standardization I mean that something should be used as default tool unless reasons exist to use something else (I do not mean that we sould impose something to everybody for all cases, but it should still be what's used in 95% of the cases). Bonjour Raphaël, first of all, I would like to apologise in public for the the unkind comment I made about your work on debian-devel. I should have sticked to the facts instead of making a bad taste analogy. This said, I think that you guess the answer I will make to your question… I think that we should not standardise on tools, but on interfaces. To take the patch management systems as an example, there is a convergence on storing patches in debian/patch, and applying them through the ‘patch’ and ‘unpatch’ targets of debian/rules. I think that it is a good situation, and I recommend against making a particular implementation the standard. The debian/rules patching and unpatching targets were not unified at the beginning, so I think that it is a nice example of that such a convergence can be achieved in Debian. I would prefer that interfaces become codified when they attract independant implementations by their popularity. Let's take the git-core package for example. It uses files like debian/git-core.docs that have a similar function and mechanism that their similar counterparts in packages using Debhelper, but they are implemented via makefiles. If listing the files to be installed in /usr/share/doc/package/ in a debian/package.docs file is for instance getting standard by its popularity, then there will be an advantage to little by little make it more formal. I think that this example can be generalised. I maintain a lot of packages that are quite trivial, so I make a heavy use of helper tools. I find that one of CDBS and Debhelper (with or without dh) is often more useful than the other in a case-by-case basis, and would be quite annoyed if one of them were removed from my toolbox. I strongly share your feeling about innovation. Trust me, when I started to oppose the way you tie your patch system to the rest of the 3.0 source package implementation, I really balanced this with the fact that going for 3.0 (quilt) is anyway better than immobilism. I decided to confront your choices because what I am asking is not to withdraw your patch system, but to make it optional. This does not close the door, it just asks the people to make the step by themselves. You also described well the difficulty of introducing changes in our core package management system. I think that we can modify our release strategy in a way that would allow point updates to that part of our stable systems. A reorganisation of package priorities and sections would help to put a frame around this, and would allow other changes that I propose in my platform. To document and standardise interfaces is a good way to ease experimentation, and therefore innovation. Also, it would help to introduce changes in a way that is backward-compatible, and give more independance between developments on interacting tools, like dpkg and dak for instance. But there will always be situations in which people need to talk together and negociate reciprocal concessions. If I am elected DPL, I will ask the delegates to make sure that requests for coordination are not ignored, and that decisions are motivated. Not answering is the worse way to say no. Conversely, it may make sense to formalise the role of the maintainers of core tools like apt and dpkg by a DPL delegation. But this particular point is not listed in my platform, and I would not make it a priority. Of course, if maintainers sponaneously request to become delegates, I will consider their proposition very seriously :) Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100325134143.ga16...@kunpuu.plessy.org
Re: Question to all candidates: How would you enforce Debian Community Guidelines?
Le Thu, Mar 25, 2010 at 05:55:35PM +0100, Hector Oron a écrit : Hello, First of all congrats to all candidates and thanks for stepping up for doing this task. Secondly, I was wondering how Debian could make it easier for people to contribute than other (derivatives and non-derivatives) distributions. I came up with a really nice draft howto[1] which I would like to bring up to your attention, so the basic question would be what do you think you could do to make contributions paths easier (take in account not all teams, groups follow such community guidelines) Kind regards and good luck ! :-) [1] http://people.debian.org/~enrico/dcg/ Dear Hector, this is a very interesting reading that I overlooked. I see it more like a turorial than a document to refer to when commenting about other person's behaviour. My main worry is that, the more complex the guidelines are, the more meta-discussion they generate if they are used as rules. Just see the quantity of traffic dedicated to complain about email carbon copies, for instance… (In theory, this particular problem has been solved smartly by Raphaël, but in pactice this update of our mailing lists's code of conduct is often ignored.) If I would have the time to propose a an additional section to Enrico's guidelines, it would be to warn against topical isolation. It is more fun, and we are stronger, when we collaborate in building interdependant works. When I started to involve myself in Debian, I wanted to create a ‘Debian-Biology’ effort but Andreas Tille convinced me to join Debian Med instead. I never regreted it. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100326004144.ga19...@kunpuu.plessy.org
Re: Q for the Candidates: How many users?
Dear Anthony, sorry for not keeping up with the answers, this campaign is very intensive ! It is interesting that your question was a kind of mini-experiment. As a molecular biologist, I like experiments a lot. Below is the draft that I never sent because I did not find time to add some flesh to it. Please take it as somehing that I thought is not ready to be sent, but that reveals bits about my state of mind before you announce the result of youre experiment. Have a nice day, -- Charles Le Mon, Mar 22, 2010 at 05:19:20PM +1000, Anthony Towns a écrit : What's your estimate of the current number of Debian users? Le Mon, Mar 22, 2010 at 02:27:23PM +0100, Bernd Zeimetz a écrit : That results in a different question for me: Does Ubuntu enforce the usage of pocon, and should Debian do so, too? Hi Anthony, Bernd, everybody, I do not know if Ubuntu has Popcon switched on by default. But on the upstream mailing lists where I am subscribed, I think that I see more Ubuntu users than Debian users. Since it is lists about scientific software, this worries me. What is Ubuntu giving them that Debian does not have? We do not play 3D games at work, and use LAN cables more often than wireless. Not to mention that Debian also provides non-free drivers for the users who need them.. -- 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/20100326010250.gb19...@kunpuu.plessy.org
No answer for insulting and accusatory emails.
Dear all, just for the record, I will not answer to insulting or accusatory emails. Some of them may contain interesting questions or comments, though. Please feel free to repeat them in a separate message if you also found them interesting. Cheers, -- Charles -- 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/20100324100932.gc8...@kunpuu.plessy.org
Re: Question to Candidates: Disappearing DPLs?
Le Tue, Mar 16, 2010 at 08:30:03AM +0100, Gerfried Fuchs a écrit : Hi! I have a question to the candidates: History has shown that DPLs more or less disappear not too long after their period or at least reduce their visible efforts immensly. I wonder where you see the reasons for this trend, what your impression is about it and wether you try to follow that trend or what you will try to do to not have this happen to you, too. Hi Gerfried, sorry for taking long to answer. This obviously demonstrates that we are not always as available as we wished. If after being elected my free time is strongly and permanently reduced, I will shorten my mandate. But I promise I will look left and right before crossing a street full of buses :) It is difficult to add much to what the other candidates and Anthony have already answered to this question. Being DPL can definitely be a final achievement that replenishes the energy and thirst for exploring other worlds. In my case, I think that I am far from having achieved my goals in Debian. When answering the “10 years” question, I wrote that I think that running Debian will mean more than just having it on one's destkop computer. I want to contribute to this adventure, this is why I participate to a Blends project and more modestly to some efforts for bringing Debian in the Clouds. I think that this combination, together with backports and snapshots, will be very powerful in the future. But this also challenges the way we publish our work. One of my motivations for standing as a DPL is to propose to the Project to expand in that direction. I think that after a one year term, I will be eager to go back to my Debian Med activities, and keep on hard work until the harvest. Have a nice day, [By the way, I apologise to all the persons who asked quiestions but did not yet get an answer. As Stefano noted, this campaign is much more intensive than last year's. This is something that I have not expected.] -- Charles -- 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/20100324145227.ga11...@kunpuu.plessy.org
Re: Question for Charles Plessy (was: No answer for insulting and accusatory emails.)
Le Wed, Mar 24, 2010 at 11:46:22AM +0100, Alexander Reichle-Schmehl a écrit : That opens up for an interesting question: What ways to settle a conflict with fellow Debian Developers seem proper to you? Do we have to expect further unspecified ignores from your side should you be elected? Le Wed, Mar 24, 2010 at 11:58:47AM +0100, Marc 'HE' Brockschmidt a écrit : OK, so I do have a few followup questions: (1) What do you consider to be insulting or accusatory? (2) As example: Will you, as DPL, consider You haven't answered in the past four weeks as accusatory? (3) How will we, as DDs, know if you consider something as insuluting or accusatory? (4) Do you believe ignoring conflicts to be a solution? Hi again, ignoring conflicts is the best way to have them explode at the worse moment. On the other hands, being insulted on a mailing list does not call for an answer. This is the best receipe for having flamewars. If I am elected DPL, I will not ignore requests. Neither will I filtrate my mailbox (but deleting spam by hand also leads to accidental loss of messages). I will read all my emails. I hope I will not disapoint you, but I will not give a lecture of what is an insult or what is not. I promise that I will not nitpick people's words to find excuses to not do my DPL work. Lastly, for the meaning of ‘accusatory’, perhaps I could have found a better word? But I am not a native speaker. What I mean is that if in one message, somebody writes ‘you want this [bad thing]’ or ‘you did not do that [good thing]’, it can be better to refrain to answer in a discussion that goes nowhere. As a DPL, however, I would clarify if people spread false informations on our mailing lists. Cheers, -- Charles -- 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/20100324153605.ga11...@kunpuu.plessy.org
Re: Question for Charles Plessy (was: No answer for insulting and accusatory emails.)
Le Wed, Mar 24, 2010 at 08:12:17PM +, Neil McGovern a écrit : The position of DPL attracts rather a lot of press attention. This at times will be accusatory, inflamatory and downright rude. Welcome to the world of journalism. Do you intend to ignore these, or just ones from developers? Hi Neil, I think I remember discussions where people were disapointed about what journalists have put in the DPL's mouth. For written interviews, I seriously consider to post my answers first on -private for comments. For something completely unrelated to Debian, I have done a phone interview in the past. While the result was not too bad, the journalist was definitely in a strong position to lead the discussion in a way that produces quite predictable answers. If I am elected DPL, I will decline that kind of interviews. If after all these precautions, there is an article that still deforms what I said or wrote, then yes, depending on the situation I may ignore it according to the importance of the media, perhaps after consulting the DDs on debian-private. Internet is very big, and to try to correct things that are written there often has the effect to make them more visible. Have a nice day, -- Charles -- 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/20100324233026.ga13...@kunpuu.plessy.org
Question about membership.
Dear all, Following the ‘Membership procedures’ GR, discussion on membership were started after the Lenny release, but eventually stopped. In this thread it was proposed to trust DDs to nominate other members and I found the idea very interesting. In order to make it more consensual, there is probably a need for making concessions like shortlisting the trusted DDs according to some criteria like the time they have already spent in the project. I would actually be tempted to propose a more variable but more symbolic measurment of time: having been part of the project for at least one full release cycle. I have put membership issues as a first priority in my platform. Partly because I have contributeed to the rejection of a proposal and feel resposible to not leave the Project in inaction, partly because I think that the the contribution of DMs is growing and I do not feel like leaving them out of the project. In my platform, I suggest in my second priority (less restricted operations) that social control can replace technical control. I think that most DMs could be DDs now. If I am elected DPL, I will re-open the discussion and lead them in a way that maximises everybody's contribution, for instance by making pauses if necessary, and by posting neutral summaries. After the discussion reaches conclusion, I will initiate a GR. So my question to other candidates is simple: what is your opinion and program about membership? Have a nice day, -- Charles -- 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/20100325001744.gc13...@kunpuu.plessy.org
Re: To all candidates: personal mentoring
Le Thu, Mar 25, 2010 at 12:15:45AM +0100, Serafeim Zanikolas a écrit : Dear candidates, I do realise that personal mentorship takes time; that's a reason to set criteria [1] and thresholds on who gets to have a mentor [2], instead of not considering the idea all together. I'd think that, in addition to encouraging more contributors to commit, this would also improve Debian's perception as a welcoming place, and new contributors' feeling of belonging to the project (would anybody even notice if I were ran down by a bus?) Dear Serafeim, I just proposed to simplify the procedures to become a member of the Debian project. But I have good memories of the interactions of my application manager when I was asking to become a Debian Developer. I think that the current NM (New Maintainer) process is a significant investment of time on possible new members. Even if the procedures for membership are changed, the concept could be kept as a mentoring system like the one you propose. Have a nice day, -- Charles Plessy, Tsurumi, Kanagawa, Japan -- 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/20100325002358.gd13...@kunpuu.plessy.org
Re: Q for all candidates: license and copyright requirements
Le Sun, Mar 21, 2010 at 01:01:40PM -0700, Manoj Srivastava a écrit : If we want to change our foundation documents, and remove the awoval to the concept of being 100% free, or to say that Debian, and thus the parts of Debian covered by the DFSG, are just the binary bits, then we can do so via constitutionally approved methods like GR's with appropriate majority requirements. Is this what is being considered? Le Mon, Mar 22, 2010 at 02:04:06PM +0100, Holger Levsen a écrit : If I understand your correctly you seem to think that your proposal wouldnt need a GR if a DPL that supports it (e.g. you) would be elected. How so? In my GR proposal, there are three options, and none of them change the DFSG. The first of them apperars quite consensual. The only problem is that if everybody agrees that we are wasting time on over-documenting debian/copyright, why don't we change our archive policy? I think that if a DPL that agrees with that change is elected, he will have a strong position to discuss with the FTP team, and a GR will be unnecessary. The second option aims at clarifying what is the source of the Debian operating system. It is controversial. Despite it does not change our fundation documents, I think that a GR would be needed to make sure that there is a general agreement. Also, I think that GRs should be used to move forward when a choice is needed, but should be avoided when the result is to demotivate many developers. I will not push the second option if this is the case (not to mention that I think that a GR should be started only if it has good chances of being accepted). I hope this explains, -- Charles -- 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/20100323150300.ga3...@kunpuu.plessy.org
Re: Q for all candidates: license and copyright requirements
Le Tue, Mar 23, 2010 at 12:04:01PM -0400, Daniel Kahn Gillmor a écrit : Our users includes not only an individual with a single computer who never sees the source, but also derivative distributions, private organizations, system administrators, etc, all of whom may need to modify the source for their own purposes. Hi Daniel and everybody, Our users, if they want to modify, study, redistribute or use after rebuild our system, need the source. At no moment these operations involve modifying a RFC or a binary program that is aimed at run on a Windows system. I conclude that that kind of file, although present in our source packages, are not part of the source of our operating system. I understand well Stefano's point of view that we serve better our users by making things clear and removing these files from our source packages so that we can say that anything that is in our main section is DFSG-free. I do not think it is so useful, however, since one can not blindly use DFSG-free material as we tolerate advertisement clauses, renaming clauses, and clauses forbidding to sell the software alone. Not to mention patents and trademark issues. I think that we should have the possibility to redistribute a bit-identical upstream archive when possible. In the title of my platform, I wrote ‘more trust’. What we can do with repacked tarballes, we can do with pristine ones. If we do not trust each other that a couple of useless non-DFSG-free files can be ignored, what else can't we trust ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100323232743.ga5...@kunpuu.plessy.org
Question for the other candidates: supermajority.
Le Tue, Mar 23, 2010 at 12:03:32PM -0700, Russ Allbery a écrit : For whatever it's worth, I believe the second option changes the foundation documents and would require a 3:1 majority. The person who's canonical on that is the Secretary. Dear Russ, Stefano, Wouter and Margarita. I would like to take the opportunity of Russ's comment to ask to the other candidates their opinions about the supermajority votes. After the very painful GR about “Lenny and resolving DFSG violations”, discussions started about our voting system, and the fact that it does not accomodate well with mixture of supermajority and regular options. Also, disagreements whether an option needs the supermajority often starts bitter debates. Do you think it is a problem that you would like to solve as a DPL? During the discussions that started after the GR, I suggested that the GR proposer should have more control about the options put to the vote. In particular, it would be useful if he can refuse an option that would disequilibrate the voting system. That would make him responsible for the success of the GR: discarding a popular option is taking the risk that the whole GR is refused and the option is accepted as a separate GR, which is the kind of public failure that I expect that people will avoid. For the supermajority, I think that it should be used only when modifying directly foundation documents. As a compensation, we may let the Secretary declare a GR ‘unconstitutional’ and refuse to let it be applied. This would remove a lot of meta-discussion in GRs that already produce many emails. In contrary with our current sytem, constitutionality of an option would only be decided after it gets the Condorcet majority. I do not think that it would create more problems than the current system, where the results of the vote can be analysed afterwards to show, if it is the case, that an option did not pass the supermajority but would be the choice of a simple majority of the developers. This is a crisis situation in general, whatever the vote system is. This said, I have not mentionned supermajority issues in my platform, since I think that the main points I propose would keep me busy enough if I am elected. I would be pleased however if somebody would self-appoint and lead this debate, if there is the impression that it is needed. Have a nice day, -- Charles Plessy, Tsurumi, Kanagawa, Japan -- 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/20100324002445.gb5...@kunpuu.plessy.org
Re: Question to all (other) candidates
Le Tue, Mar 23, 2010 at 06:49:51PM +0100, Wouter Verhelst a écrit : Charles: In your platform, in the Program section, you mention four ideas that could reasonable be described as being about the things that, respectively, the DAM and NM frontdesk, the ftp-masters, and the Release Managers (twice) are responsible for. Did you talk with these teams about your ideas before running for DPL? If not, do you believe this may cause problems? Are you still planning to, and may your ideas change if you do? If you did talk to these teams beforehand, did your plans change any as a result, or do you anticipate that still happening? Hi Wouter, I have not contacted these teams in private or in public. I expect the three weeks of campaign to be long enough to openly discuss what I propose. Also, I do not think that we need a conclusion now; what we need is to agree that a door is open to change some of our practices. In my platform, I have separate sections for ‘Program’ and ‘What I will do as DPL’. In short: vote for my if you like my program, but I will not come to the core teams with a long shopping list of things to do. This is not fun, nor it gives trust to the teams that do the work. If I am elected, I will contact the core teams about the main points of my program as general directions that, together, collected a majority of the votes in this election, and propose to discuss them in public. I want the outcome of these discussions to be open: we can find other ideas. Have a nice day, PS: interestingly, I just rediscovered an email that covers part of my platform in my ‘postponed’ folder, that I wrote for -devel last year but never sent. Last time I tried to discuss about not building everyting on all arches I was insulted, and this made me affraid to discuss this again in public for a while… -- Charles -- 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/20100324015421.gd5...@kunpuu.plessy.org
Re: Q for all candidates: license and copyright requirements
Le Sun, Mar 21, 2010 at 01:49:28PM +0100, Bernd Zeimetz a écrit : Charles Plessy wrote: 2) I think that the Debian operating system is defined by the interaction of its binary version and the source files necessary to use, study, modifiy and redistribute it. Non-DFSG-free files that happen to be codistributed with the source of the Debian operating system but have no function at all are not part of the system, and I would like maintainers to be allowed to keep these files in the original upstream material if it simplifies their work. Would that include files which we are not allowed to distribute (for whatever reason)? Do you think that the number of packages where the source had to be repackages is high enough to warrant a change of the DFSG? I think that we must not redistribute files that we are not allowed to redistribute, be they part of our operating system or not. I do not propose to change the DFSG, as it it relevant to the Debian operating system only, not to everything that the Debian project distributes (otherwise, we would not have a non-free section). I think that if a file that has no function in our operating system happens to be co-distributed on our source medias, like a RFC, a PDF file for which upstream forgot to provide its LaTeX source or a windows executable, our operating system is still DFSG-free. I use “More fun” in the title of my platform. DFSG-repacking is not fun. It provides no extra freedom, creates nothing, and syphons time and motivation (at least mine). I think that developers who do not go through NEW every month do not realise how long we spend repacking and cut-pasting coypright notices. In the meantime, other distributions innovate. One of my main motivations to stand up for DPL is that we remove all the barriers that contribute to Debian's immobilism. The copyright collection and tarball repacking are, in my opinion, one of them. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100321145732.ga4...@kunpuu.plessy.org
Re: Q for all candidates: license and copyright requirements
Le Sun, Mar 21, 2010 at 02:42:51PM +0100, Stefano Zacchiroli a écrit : On the contrary, I'm against point (2) of the GR. I do consider our source packages to be part of Debian and hence subject to DFSG. If something in upstream tarball is non-free, I believe we should do repacking (there, we might use a bit more standardization on how we implement get-orig-source in such cases, but that's a different issue). In fact, doing that might even be a way to push our upstream to get rid of those non-free bits from their tarballs as well. Hi Stefano, I explained in my GR proposition what led me to conclude that not everything in the original archives distributed usptream is a source for Debian. Let's take a non-free RFC for example, that is not distributed in a binary package and is not touched at build time. Why do you think it is part of the source of the Debian operating system? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100322004708.ga8...@kunpuu.plessy.org
Re: Questions for all candidates: decentralization of power
Le Fri, Mar 19, 2010 at 06:44:23PM +, Clint Adams a écrit : I had meant to send three sets of questions on Thursday morning, but things kept coming up, so I will send an unfinished one now. 1) 114 people have commit access to webwml. 2) wanna-build access is restricted 3) An ftpmaster cabal 4) The tech-ctte has the power to appoint its own members. 5) Is there any part of Debian that should be restricted to a small subset of developers, and if so why? Dear Clint, I also think that there are many restricted operations that should be opened. Write access to our website, chosing the priority and section of our pacakges, triggering bin-NMUs, designating new members, inspecting new packages submitted to our archive, … I see two possible reasons to keep some restrictions. a) Social. Just writing that we think that restrictions must be lifted is not enough; we need to be convincing. If a majority of DDs agree to open only a part of the infrastructure, I think that it is better to accept the remainig restrictions, and re-open the discussion in one or two years later when we can show the benefits. b) Security: if one DD account is compromised, some mechanisms can limit the harm caused by intruders. For instance, there could be a temporisation system that delays for a couple of hours the effect of some commands, and I would agree to have a restricted number of persons with the ability to bypass this temporisation, for instance when some critical dysfunctions have to be corrected immediately. Lastly, I think that we need some referees for our technical disagreements, and the technical comittee fits well that role. If I am elected DPL, I will ping its members and ask them if they would like to leave their seat to fresh persons. I do not think that it is a bad thing that the comittee is not elected. Its role is not to proportionaly represent currents of opinion within Debian, but in contrary to make decisions that reflect the Project's consensus. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100320154644.ga2...@kunpuu.plessy.org
Re: Q for all candidates: license and copyright requirements
Le Sat, Mar 20, 2010 at 07:45:30PM +0100, Bernd Zeimetz a écrit : Hi all, with 20100124144741.gd13...@kunpuu.plessy.org Charles Plessy came up with a draft GR Simplification of license and copyright requirements for the Debian packages.. I'd like to know from Charles Plessy if the draft from January still reflect his current opinion or if his mind changed. Dear Bernd, my current opinion is reflected by 20100207153515.ga20...@kunpuu.plessy.org, in which I clarified my proposal according to the first round of comments. In summary: 1) For the reproduction of copyright notices, let's do what law and licenses require from us, and not more. 2) I think that the Debian operating system is defined by the interaction of its binary version and the source files necessary to use, study, modifiy and redistribute it. Non-DFSG-free files that happen to be codistributed with the source of the Debian operating system but have no function at all are not part of the system, and I would like maintainers to be allowed to keep these files in the original upstream material if it simplifies their work. Lastly, I am not sure if I will ask sponsors for this GR, as I wrote: ‘A GR that is accepted by a large majority is not necessarly a waste of time, because it dissipates misunderstantings that can arise with tacite agreements. But yes, there are alternatives, like electing a DPL that supports this change in his platform.’ So I am definitely interested to read the opinion of the other candidates :) Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100321021728.gd31...@kunpuu.plessy.org
Re: Questions for all candidates: decentralization of power
Le Sat, Mar 20, 2010 at 05:59:35PM +0100, Jan Hauke Rahm a écrit : I'm not sure I understand you correctly here. Are you saying that you will -- if elected DPL -- suggest the current members of the technical comittee to step back just for the sake of having new people in their seats? Le Sat, Mar 20, 2010 at 12:04:33PM -0700, Russ Allbery a écrit : I'm a little bit confused about why you would do this. Could you explain more what the motivation would be? Hi, I think that a good ping email contains an invitation to think about one's involvement in the future. People may forsee a reduction of the time they can give to Debian, or they are increasingly interested in other activities within Debian. Unless we think that nobody else than the current members are qualified for the task, I think that it is useful to remind them that they are free to pass the baton if they wish. I will not propose to the chairman of the technical comittee to rotate a member who has answered to the ping. Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100321030437.ge31...@kunpuu.plessy.org
Re: Question for all candidates: Release process
Le Mon, Mar 15, 2010 at 08:09:19AM +0100, Lucas Nussbaum a écrit : During the last debconf, the freeze of squeeze was first announced to take place in December, then this decision was cancelled, and now we are in March. - How do you analyze what happened during last summer? What went wrong? - What is your opinion on the motivations for the proposal to freeze in December? Specifically, in the future, should we try to coordinate our release process with Ubuntu's? - So, we are now in March. What is your opinion with the release process so far? When do you see the release happening? Hi Lucas, I was really disapointed when I read the press release. After announcing a decision to the public, it is very difficult to change it; it really gave me the impression to have my arm twisted. The freeze of Lenny was quite long, and I tried to play the game, not updating my packages but doing release-oriented work (including some tasks very specific to Debian Med, which did not have an impact on Lenny's releasability). As a consequence, I was very worried that I would not be able to update my packages to all the new upstream releases that happened during the freeze, if we would freeze again in December. This said, I am well aware that all my packages are not essential to Debian's life, and I decided to not complain too much and trust the judgement of the release team. However, my personal opinion was that it is not a good idea to release Debian with packages less up to date and a shorter security support than Ubuntu. I would rather release on the years where there is no Ubuntu LTS. This way, people trained to use dpkg-based distributions have the opportunity to install a recent release with a reasonably long support each year, instead of each second year. I think that this would maximise Debian and Ubuntu's user base. In this elections I propose to change our release philosophy. Depending how oftern the kernel, libc, GNU, GCC, X.org, and other bright software stars align in the sky, it could mean that we could release a core distribution more often (than each second year) if we were interested in committing to this effort. Still, a synchronisation with Ubuntu is taking the problem in the wrong direction, I think. I do not have a long experience in collaborations with Ubuntu but it seems that to meet deadlines, they do not hesitate to diverge with upstream projects much more than what we are used to. I do not think that we shall follow them in this path. I see more collaborations made on opportunity basis, when both distribution's choices are naturally converging. We can not promise to be ready to release the 1st of April 2012. Now we are in March and I do not know when we will release. For the Lenny release, with the release goals, the progressive freeze and information emails from the release team, we went through milesones that I think helped a lot the Project have a good feeling of the timing. The last footstep took more time. It was written often that it is because there were too many RC bugs, but I think that the true reason is that we were waiting for the installer team. I do not write this to throw a stone to them, but to repeat once again that fixing abandonned package does not make the release closer [but if you have fun with this, do not stop! Debian is also about having fun]. Turning the spotlights on the most difficult blockers would be very helpful. I do not know if we can release soon, in the sense that I do not know if the packages providing the core functionalities of our operating system are ready. Honestly, as a DD I am not interested to fix bugs like python packages that do not work with version 2.6 if the maintainer does not at least ask for help (I would rather be interested to participate to bolder package removal sessions). If many other DDs share the same impression, and if all RC bugs are left in the same bag without indication of priority, then we probably will not release soon. Milestones like freezing the toolchain would send a strong message that it is time to refocus our efforts from our own packages and team to the last blockers. Since the original plan was to release with Ubuntu LTS and that will not be done, as a DPL I would ask the release team to update the project on its plans. Have we lost the announced benefits of a joint release and postopone for more than a couple of months to allow more developments, or are we very close to freeze our core toolchains anyway ? Frans Pop wrote an insightful email on how the release is also a lot of communication work. If I am elected DPL, I will emphasise this role in the delegation given to the release managers. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100319012849.ga1...@kunpuu.plessy.org
Re: Question to all the candidates: communication
Le Sun, Mar 14, 2010 at 10:17:06AM +0700, Paul Wise a écrit : Which project and external Debian-related communications media do you follow? and contribute to? As well as a general list I'm interested in specific lists (for eg #debian, #debian-devel, debian-de...@l.d.o, debian-proj...@l.d.o, the Hardware forum on forums.d.n etc). Hi Paul, Raphael and everybody, For the general lists, I am subscribed to -devel, -project, -devel-announce, -private, -vote and -policy. As part of my packaging activitites, I am also subscribed to -med, -science, -blends and more recently -qa. I also lurk on -powerpc, because I used Debian on a G5 for a couple of years, but I am not really contributing anymore there. Et bien sûr, je suis aussi sur -french et -devel-french. On the web I read Planet Debian, but never visit forums. I do not go on IRC either (too fast for me). I sometimes attend the Tôkyô area Debian study group, but it has become quite rare because I often decide to stay at home to pet my packages instead, or to join a monthly saké-tasting party that often hapens the same Saturday… If I am elected DPL, I will temporarly reduce my activities in the Debian Med project. But I will take more opportunities to meet other DDs in Japan. I will not significatly change my mailing list subscribtions. I will go on IRC if something is planned there, but not on a regular basis. I will use the -devel-announce, -devel, -project and -private mailing lists as main communication channels, and refrain to make fresh announces elsewhere. I will report about the spendings I approved every two months, perhaps on -private if it discloses too much personnal informations, and send a general report every other month on -devel-announce. Lastly, although the atmoshphere improved, I would like our mailing lists even more free from aggression. Things like invitations to stop whining, to change project, and questions about one's mental health hurt, are inappropriate and off-topic, and increase the noise. I will ask the listmasters to not hesitate to ban people for a couple of days if they post a completely useless and aggressive message. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100317143657.ga23...@kunpuu.plessy.org
Re: Q for all candidates: (Old) Architecture Support
Le Wed, Mar 17, 2010 at 03:49:16PM +0200, Yavor Doganov a écrit : * There should be an entitiy within the project to decide which arch gets released and which not, which one is blocking the whole release process and ought to be ignored for testing propagation, etc. Naturally, such entity is the Release Team, and their criteria don't seem bad. Hello Yavor, I do not completely agree with this: I think that the porters should have much more latitude on how to what their port contain. If they can assemble a reasonable subset of Debian's packages into a working system that matches the expectations of the users and that Debian can be proud of. Other teams (security, toolchain maintainers, …) are qualified to tell if releasing a port with that given subset would perturbate their work and therfore the other ports, and the release team would then be the one to take the final decision. I think that a simple reorganisation of our archive's sections and priorities would open the way to such lighter releases. Efforts of developers would be rewarded earlier. Architectures that lose their mainstream position and therfore upstream support in popular heavy-weight applications could survive much longer. As Wouter noted, it is probably when the core toolchain is not maintained anymore that the port is severly compromised. By the way, I would like to react to one of Wouter's comment, that package maintainers should fix the porting bugs themselves. I really disagree. As a pakcage maintainer, I found myself a couple of times in this kind of situation, where nobody wants to do the work. This is a totally fun-killing situation. The port threaten's my package's seat in the release, and my package threatens the port's existence. Yet nobody ever complained that the package is not available for that port… What I mean by my not-so original ‘more fun, more trust’ credo in my platform, is exemplified in this situation by the fact that if nobody wants to fix the bug, it is a good indicator that everybody has more important, more rewarding, and in the end more fun things to do, and that we should trust their judgement by changing our release strategy instead of maintaining an institution that opposes people. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100317150256.gb23...@kunpuu.plessy.org
Re: Will you withdraw delegations of DD not behaving correctly?
Le Mon, Mar 15, 2010 at 08:13:23AM +0100, Raphael Hertzog a écrit : What do you think of this and would you be ready to withdraw a delegation for a delegate that behaved badly towards another DD (even outside of his delegated role), that has been warned once by you and that did it again later on? Do you think we can draft a code of conduct for Debian and do you think you can ensure that it would be respected by delegates? Dear Raphaël, the role of many delegates is to lead a team, and as such they need good social skills. Biting back people who criticize their work is not a good way to defend their team. In contrary, it turns down contributors and isolates it. I would like to add that aggression is not the only bad behaviour. Refusing answers is also a way to demotivate and put aside people. I think that the role of a delegate is to communicate even with the developers he does not want to work with. (If some people abuse the delegate's time with repetitive requests, that is another story). If a delegate repeatedly misbehaves or fail to communicate, I will ask him to step down in a mid/short term, ideally at the opportunity of a notable achievement. I think that it is important to leave to people a possibility to save the face, expecially with on-line projects like Debian that leave a permanent trace in the Internet search engines. Changing a delegate should not be a personal punishment, but a way to get things done better in Debian, so despite that “we will not hide problems”, I will not have the discussion with the badly behaving delegate in public (but perhaps on debian-priv...@l.d.o if I have the feeling that the Project is expecting it). Lastly, I do not think that we need a code of conduct. I am worried that it would generate too much meta-discussion. I think that it it enough to remind newcomers that when we do not know personnaly the recipient of our messages, there is a high risk that anything too causal will be misinterpreted. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100318011536.ga18...@kunpuu.plessy.org
Re: Question for all candidates: Release process
Le Sun, Mar 14, 2010 at 02:44:15PM -0700, Russ Allbery a écrit : Releasing is regularly the hardest thing that Debian does, not just technically but also socially. Apart from the standard issues of setting deadlines, RC bug counts being high, and similar difficult technical issues, the process seems to eat volunteers. Dear Russ and everybody, I think that our release process is manpower-hungry by design, and that the more packages and architectures we have, the harder the release is. I propose to refocus our efforts. Solving a thousand of RC bugs is a herculean task for a small group of persons. But why should they do that in the first place? Most of these bugs are the responsibility of the package maintainers. If they can not make their package ready for the release, will they be able to help for stable support? Who will do that work? I propose that we reshape the sections and priorities of our archive, so that it is easy to remove from Testing any RC bug that is not in a core pakcage, and is old and not tagged RFH. In parallel, I propose that the definition of what the ‘core’ is can vary between architectures. The goal is not only to reduce the workload of the release team and the porters. It is also to give some meaning to the presence of a package in a stable release. These packages must be there because there is agreement that enough users are insterested in it, and are comfortable with the idea to keep it at the same version for a long time. For many peripheral leafs and branches of our dependancy tree, let's innovate and distribute them through other channels, like official backports and even the new snapshot system that is being set up. When all of this is aptable from the official Debian mirrors, it will open great opportunities to build tailored Debian systems, for instance with the ‘blends’ framework. Debian is volunteer-driven, so the release can only happen by coordination. Acutally, it is a coordination process by nature: a release is a moment in the development where all the core components work well together. If these components evolve independantly, it will hardly happen by chance. Motivation must be there on both ends. This is why I propose to limit the release to the packages where there is a real motivation for it. When maintainers feel the need for a release, they will have to talk to the others and eventually make concessions on their timeline. Not to mention that for many of our packages, there is actualy nobody who regularly cares for them anymore. In that sense, I think that membership issues are one of the roots of our difficulties to release. As a DPL I will help the Project to evolve its release and membership process through my constitutional roles: leadership in discussions, GRs, and delegations. I expect as a result that the release work will become much more social than technical, with all participants doing their part of the housekeeping work. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100317005207.ga6...@kunpuu.plessy.org
Re: Question to all Candidates: Heated discussions
Le Sun, Mar 14, 2010 at 02:40:32AM +, Dmitrijs Ledkovs a écrit : Hello =) Hello again :) Sometimes technical Debian discussions (mailing lists, bug reports, blog posts, etc.) become personal flame-wars. Do you think current frequency/amount of heated discussions is acceptable for the Debian project? What would you do to reduce those? One way to cool a heated discussion is to add a lot of ice on it. Very few of our communication media really need to be repsonsive in real time. Especially on our mailing lists, I would not mind if the admins would have a big red button that would suddenly delay any email posted there of a couple of hours. I think that some mailing list systems implement that capacity. Of course, self-cooling is much more friendly. Even in constructive threads, I try to limit myself to one or two messages per day when they are on central mailing lists. I really invite the other subscribers to do so. In order to get as many insights as possible, we must remember to keep the door open to other contributors. And if after two days of absence, there is a 100-mails thread in their mailbox, I think that the door is closed. Also, as a DPL I will make an effort to prepare neutral summaries that resurect important discussions that had a productive part, but were killed because one part of the thread exploded in a deluge of emails. It is important that people have the guarantee that their opinion will be taken into account even if there has already been 50 emails exchanged by other persons. This will be another incentive for everybody to just press the delete button and let things cool down. I would also welcome much stricter policy about voluminous off-topic discussions, and invite the listmasters to ban for a couple of days people engaging in this behaviour. Many personal flame-wars fall under this category. In addition, I think that we should reduce our institutional tolerance to aggression and insults. We already often underestimate how we can hurt others with simple words and direct criticisms. Attacks are unacceptable. This said I think that everybody loses control sometimes in their life, and we should welcome sincere excuses. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100315151317.ga32...@kunpuu.plessy.org
Re: Question to all Candidate: In ten years...
Le Sun, Mar 14, 2010 at 02:35:28AM +, Dmitrijs Ledkovs a écrit : Hello =) Please finish In ten years I'd like Debian Dear Dmitrijs, In ten years I'd like Debian to be mainstream. Our biggest competitor is not the proprietary operating systems anymore, it is all the closed-source gratis online applications. Debian, as a universal operating system that provides the applications on the server and the tools to access them on the terminal, is a necessary answer to that threat. In 10 years, when people say “I am using Debian”, I would like that they mean that Debian is powering both ends of the software chain they use, that they chose it because the software is free, because they trust our Project, and because we provided easy ways to set up application servers in local communities. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100315013555.ga15...@kunpuu.plessy.org
Re: Question to all candidates: financing of development
Le Sat, Mar 13, 2010 at 08:18:00AM +0100, Raphael Hertzog a écrit : Imagine a DD contacts you, she wants to setup an infrastructure to finance Debian related projects (i.e. paying people to enable them to work on the projects that they'd like to do for Debian) but she wants to avoid the main mistakes made during Dunc-Tank; in her project: - everybody can propose projects to be financed - the projects to be financed are selected by the Debian developers and by the donors - eligible projects can only concern new developements and not recurring tasks Hi Raphaël, I see two separate processes in the infrastructure that you describe above: - A meeting point where project proposers can find potential sponsors. - An endorsment system where the Debian project supports project that meet some criteria. I wonder if there are already existing platforms where projects can be proposed for funding. The Google Summer of Code is a very special example, but there may be more generalist ones. Why not simply use them instead of setting up a new infrastructure? Then for the endorsement, I would propose to nominate delegates after discussion on debian-project, if we find volunteers to deal with the requests for official blessings. What I like in your proposal is that the projects will need a donor, as opposed to directly use Debian money. I think that showing the capacity of finding a donor is an important filter before engaging a contractual relationship with people to deliver software developments. Also it is important to decide the person and the price at the same time as proposing the project, and leave to the donor the decision whether the price is reasonable. For an global project like Debian, it is a very difficult problem to solve, as one hour of development has radically different costs around the world… Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100313083648.ge11...@kunpuu.plessy.org
Re: Question to all Candidates: 2IC
Le Fri, Mar 12, 2010 at 01:12:57AM +0100, Joerg Jaspert a écrit : Heyho, a little question to all those up for the next DPL: Do you plan on taking on a 2IC or a team? If so: Who? And why this/those? Hi Joerg, If I understand correctly, the 2IC is another person that gets the emails for lea...@debian.org. I hope that the traffic on this address is low enough and that I can take vacations without blocking the project, so I do not plan to team up with a 2IC. I do not plan either to assemble a team. I think that the role of the DPL is to help the Project to keep cohesion and avoid inertia, and I am not sure that a team will be more efficient in this than a single person: if we stimulate Debian in many different directions, the opposite effect can be reached! Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100312155132.gb10...@kunpuu.plessy.org
Re: Question to all Candidates: Project Funds and donations
Le Sat, Mar 13, 2010 at 12:02:59AM +0100, Martin Zobel-Helas a écrit : The Debian Project receives quite a number of monetary donations as well as contributions in kind via several umbrella organization like SPI, ffis, debian.ch, etc. a) What do you think are valid goals to spend this money on? b) How would you think is a valid way to thank (hardware) contributors? b) What qualifies a contributor to become a Debian Partner? What qualifies a Debian Partner? Hello Martin, The discussion initiated by Steve about how to use our money did not reach a conclusion, and I think that it shows how delicate that subject is. From this thread, I personally conclude that direct donations (hardware, bandwidth, booth space, time, meeting rooms, …) are much more valuable for a project like Debian, whose do-o-cratic traditions do not accommodate with open questions like how to spend our money. Direct donations are in essence more focused, and very importantly are more rooted to reality: we get what our sponsors produce or use; what they give to us influence how we grow. That is a much more intimate relationship than money exchange. So to answer your first question, I think that the Debian money is best spent on what we can not receive by donation. The biggest examples that come to my mind are shipping hardware between private locations and helping people to travel and meet. In particular I will not agree with paying to develop software. Also if we do not manage to spend our money in a meaningful manner, I think that we can modify the donations page of our website to reflect that direct contributions have a much more immediate effect than sending money. Our project does not accept non-voting members nor legal persons (companies, associations, …) as members. In the long term, I think that it would be useful to re-open the discussion on membership, and that would be a good opportunity to give a more formal definition of what a Debian Partner is. I suppose that the concept was created before I joined the project, because I do not remember a discussion on the subject. There is a detailed description on our website (http://www.debian.org/partners/partners) and I am sure you know it, so I suppose that you are also asking what the candidates are thinking of this definition? I agree on its core, that the partnership must be an ongoing story. It does not mean that point contributions are not appreciated, but I think that only with this criterion (contribution that is ongoing), we can aim at maintaining an accurate list of partners. Of course, thanks for past partners or point contributors are much welcome as well. If tomorrow we receive a large donation, we can make a press release together with the sponsor; this press release will have even more echo than being listed on our Partners page. After visiting our website, I saw that the Partner Program is listed in our organization page, with names of active persons. I admit that I have no idea if they are DPL Delegates or not (and I intent do make a general ping and inventory, but that is off-topic here). I think that the role of the DPL is to make sure that teams that take decisions in our name are doing so in a consensual manner, but I do not think that the DPL has to be intrusive on the details. So I will not comment on the details on the Partnership Program. Therefore, the answer to your questions are that what qualifies a Debian Partner is currently decided by the Partners team, and as a simple developer I am not aware of major disagreements about their work. I note however that the page describing Partners is not completely up to date (Financial Partners from page http://www.debian.org/partners/ are not described in the partners/partners page). Perhaps if that team had more visibility (it has no description on http://wiki.debian.org/Teams either) it would attract more contributors? In a separate part of my platform, I will propose to give more detailed delegations and collect them in a single reference point, not only to avoid misunderstanding on who does what, but also to advertise teams that are lead by DPL Delegates and help them to attract manpower. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100313035746.ga11...@kunpuu.plessy.org
Re: DPL Elections 2010: Last call for nominations
Le Thu, Mar 11, 2010 at 02:13:13AM +0100, Wouter Verhelst a écrit : Well, if nobody but Zack is going to run, that would make for a rather dull and boring DPL election period. So I'll run, too. Hi all, I was hoping this would not happen, but if Stefano is not the only candidate, I will run as well. The main lines of my platform will be: - More trust to the DDs, - Easier entrance and exit in the Project, - More information (spendings, SPI lawyers, …) - General ping, appointment and rotation of the delegates, - Proposition of (not so) new paradigms for our releases, - More fun, less insults. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan signature.asc Description: Digital signature
Re: Draft GR: Simplification of license and copyright requirements for the Debian packages.
Le Sun, Feb 07, 2010 at 02:08:29PM -0800, Thomas Bushnell BSG a écrit : On Mon, 2010-02-08 at 00:35 +0900, Charles Plessy wrote: 3) Is there a benefit of allowing non-free files to be distributed together with the source of the Debian system ? Have you considered the harm? It means that users can no longer assume that whatever is in the source packages can be distributed by them under the DFSG. Especially since your proposal is all about making copyright information harder to locate, you are making things far harder. Hello Thomas, Indeed, there are pros and cons for my proposal. I have mentionned in my first message that with our current practice, our users know that – human errors excepted – everything they get along with the sources of the Debian system is DFSG-free. http://lists.debian.org/msgid-search/20100124144741.gd13...@kunpuu.plessy.org However, even when all the files are DFSG-free, one can not blindly redistribute or modify them, because we distribute works with an advertising clause, or works that require to rename the programs in case of modification. Therefore, one has anyway to check the licensing details for any DFGS-free file redistributed. About the visibility of the non-DFSG-free files: I wrote my proposal to be broad, not as a patch to the Policy. If the GR is voted and accepted, nothing prevents the Policy to require that non-DFSG-free files are marked as such in debian/copyright. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Draft GR: Simplification of license and copyright requirements for the Debian packages.
Hello again everybody, I did not have much time recently, so here is a summary email that tries to answer in a single message all comments that I received in public or private. 1) About the exhaustive reproduction of all copyright notices. I have the feeling that there is a consensus that we do not need to do what laws and licenses are not commanding, but unless votes are counted with a GR, this is only my feeeling and nothing else. I think that a GR is the right instrument to check the consensus over big changes, and that the relaxation of our policy of documenting all copyright notices is a big change. A GR that is accepted by a large majority is not necessarly a waste of time, because it dissipates misunderstantings that can arise with tacite agreements. But yes, there are alternatives, like electing a DPL that supports this change in his platform. The proposition that I make is deliberatly not a Policy change. First of all, it would introduce diffcult debates whether it can be edited later without another GR. Second, I do not propose to replace the definition of debian/copyright. In particular, this GR says nothing about other contents of this file such as the URL to the sources. Rather, if accepted this GR would be the green light for a Policy change. 2) About the source of the Debian system. I would like to take the opportunity of this message to make a clarification on what I wrote about ignoring the DFSG (http://lists.debian.org/msgid-search/20100125010005.gf13...@kunpuu.plessy.org). The DFSG are guidelines, and it is our social contract that tells us when to follow them. We must not ignore them in these situations. What I am arguing is that some files that are in the orig.tar files distributed in the source packages of the Debian system are not part of the source of the system, and that for them the DFSG do not apply. This is what I meant when I answered yes to MJ Ray when he asked me if I proposed to ignore the DFSG. Similarly, I do not think that it violates the title of the point one of our social contract (“Debian will remain 100% free”). The Debian project maintains and distributes non-free packages, so I conclude that the title – concise by nature – is about the Debian system, and not about everything made by the Debian project. Maybe it is because I am a biologist, but for me ‘Debian system’ means something functional, something that one can run to operate a machine. Without its sources, that system is not free. But the collection files distributed in our source packages do not define what the Debian system is: some ‘convenience copies’ of software libraries are ignored and we do not provide support for them ; they are not part of the Debian system. Moreover the possession of only the sources is not is enough for making and using a free system: one can not do anything with an empty computer and the sources alone. For me, it is the combination of the binary programs and their source that make a free operating system and define its boundaries. If on the medium that contains the system's sources there are other files that have no function in the system, then it is my point of view that they are not part of it. 3) Is there a benefit of allowing non-free files to be distributed together with the source of the Debian system ? There are clear benefits. Firstly, would allow to use a bit-identical source material as distributyed upstream. In the future, it would allow to distribute source packages based on repository clones that contain freely redistributable non-DFSG-free material, without having to engage in complex extirpations over the entire repository's history (since we would still be distributing the files after deleting them from the head). There is also a time benefit. Repacing a package is less than one hour of work, but multiply it by many packages, and it becomes a significant amount of time. Lastly, it is not fun, and having fun is a very important motivation in volunteer work. Doing boring, repetitive and not fun work leads people to make errors, which waste other people's time even is they are as minor as forgetting to add a mangle rule to debian/watch in order to take the ~dfsg suffix of the Debian upstream version. Here is a revised version of the GR proposal (still unsigned to underline that it is still a draft), that I hope clarifies point 2) Have a nice day, -- Charles Plessy, Tsurumi, Kanagawa, Japan General resolution: Simplification of license and copyright requirements for the Debian packages. Motion A: The Debian binary packages contain an exhaustive summary of the licenses of the files it contains. This summary also contains a reproduction of the copyright notices when the license require it. Additional documentation is encouraged but not necessary. Motion B: The Debian binary packages contain an exhaustive summary of the licenses of the files it contains. This summary also contains a reproduction of the copyright notices when the license
Draft GR: Simplification of license and copyright requirements for the Debian packages.
Dear all, a significant part of the time dedicated to make and update Debian packages is spent in making an exhaustive inventory of the copyright attributions of the distributed work, and to clean the upstream original sources from files that have no impact on the binary packages we distribute. After a couple of years spent as a Debian developer, my personal conclusion that this time could be better spent for other efforts. I therefore propose to make these practices optional. Since it is a major change in our traditions, I propose to make a GR to make sure that there is a consensus. 1) The copyright attributions. The inventory of copyright notices that we distribute together with our packages is checked at the first upload only. At this step already, some packages with incomplete lists are accepted. For other packages, new copyright notices added upstream during updates are missed and the Debian copyright file is not updated. As a result, for the purpose of having an exhaustive listing of all the copyright notices present in the Debian source packages, the debian/copyright files are not a reliable source of information. I do not think that we have the manpower, nor perhaps the will, to do this inventory with the same aim of perfection as we have for other matters like security or stability for instance. Since not all license require to reproduce the copyright notices in the documentation of our binary packages, I propose to give up this self-imposed requirement, and simply focus on respecting the licenses. I have considered whether doing so would increase the work load of our archive administrators. I have some experience of NEW package inspection (http://wiki.debian.org/CopyrightReview). In my experience, the debian/copyright file is not an aid to the reviewing task, since the very goal of this task is to check if nothing has been omitted or incorrectly copied. The license of the redistributed files have to be inspected anyway, and at this moment it is usually clear whether the license has some clauses about the reproduction of copyright notices. 2) The non-free files that we remove from the upstream sources. Some upstream archives contain files that are not free according to the DFSG, but that can be omitted without affecting the programs distributed in our binary packages. Typical examples include non-free RFCs, sourceless PDFs, GFDL documentation, copies of scientific articles licensed with a clause prohibiting commercial use, or builds of the program for MS-Windows. Repacking the upstream sources to remove such non-free files does not provide any additional freedom. Among the disadvantages of repacking, there is the work overhead for the packager, and the loss of transparency for our users as we do not distribute a bit-wise identical source archive as upstream anymore. Among the advantages, our users know that if they download our source packages, there is non-DFSG-free file in. I think that this advantage is not as big as we think. Since we allow licenses with an advertisement clause and licenses that forbid to reuse the same program name for derived works, our users have to check the license of our packages in any case and can not blindly redistribute modified versions without checking for the above two points. So the presence of legally redistributable files that do not satisfy the DFSG in our source package would not change our user experience, especially that the target is files that can be ignored. Most importantly, none of these files would be distributed in binary packages anyway. According to our social contract, “We promise that the Debian system and all its components will be free according to [the DFSG].” My understanding of this is that the Debian system, our binary packages, is free and therefore we distribute its sources, the source packages. If these source packages contain non-free files that have no impact on the binary packages, I think that it can be said that they are not part of the Debian system. Therefore, despite what I propose is a big change from our traditions, I do not think that it is a change that contradicts our foundation documents. Draft of the GR --- I propose three motions that can be seconded separately. The first implements the point 1), the second points 1) and 2). Given that point 2) is likely to be far more controversial than 1), I do not think that there is a need for a motion that addresses 2) but not 1). Lastly, remembering the bitter experience of the two GRs of 2008, I propose a third amendment to strongly reject the GR and blame for having submitted it, in case I strongly misunderstood the situation and harmed the project with this GR. Also, it allows the ‘further discussion’ default option to really mean that more discussion is needed. Have a nice day, -- Charles Plessy, Tsurumi, Kanagawa, Japan General resolution: Simplification of license and copyright requirements for the Debian packages. Motion A: The Debian
Re: Draft GR: Simplification of license and copyright requirements for the Debian packages.
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. Doing this on purpose would of course be a big hypocrisy. We could mention in the GR that it is not acceptable to repack an upstream tarball for adding a non-free file, nor to include some in the debian diff or tarball component of the source package, nor for Debian to distribute its own developments as source packages containing non-free files since we have to show the way (note that not all packages in native format are Debian developments). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
