Re: Standardization, large scale changes, innovations
On Wed, 2010-03-31 at 18:13 -0700, Russ Allbery wrote:
Wouter Verhelst wou...@debian.org writes:
My father, for instance, often drives a screw into a piece of
wood with a chisel when he doesn't have a screwdriver around.
And I've also seen him chop off bits of wood with a
screwdriver, on occasion.
I like this example... If I were using a screw driver when I should use
a chisel, I would be rounding off the shaft of the screw driver, which
makes it unsuitable to screw at some point (and I am likely to hurt
myself too)
If I use a chisel to screw, I am spoiling the screw (and I am likely to
hurt myself too)
In both case:
1. I am shooting a bullet in my own feet, as I am making my futur
significantly tougher, just to a little bit lazy now.
(Also, this is really not nice if I am working with someone).
2. Not using the appropriate tool is amateurism. If you ever hire a
professional, which happens to do such thing, then just fire him off
before he makes a mess. (I am not suggesting to fire off any DD that
don't use dh ;-)
The same is true with Manoj. You may think debhelper is the best thing
[[[droping personal statements]]], but Manoj just disagrees. And as long
as Policy does not specify that debhelper is to be used, it's perfectly
within his right to not use it.
I think you just overlooked my previous email, especially the part about
industrializing.
http://en.wikipedia.org/wiki/Not_Invented_Here -- replace here by ${me}
There isn't just Manoj that work on Manoj's packages (QA team, Security
team, Derivative distro... and our users!). BTW, does Manoj own those
package?. As I wrote those lines, I wonder if some developer don't
precisely use home made stuff to say keep out, this is my own package.
A best practice isn't a standard (or a policy), still most people follow
it.
As long as the result is good -- a working, policy-compliant package
-- how he gets that result is not your business.
Isn't Debian an organisation (with 1000+ developers)?
If you think otherwise, you should first get Policy changed, and then
complain to Manoj.
That's an easy move... (anyone who disagrees has to turn his proposal
into a policy!)
Also, as a general rule of thumb, Policy should be about standardizing
interfaces, not about standardizing tools. What matters from a Policy
perspective is what ends up on the system, what ends up in the package,
and how the packages interoperate for the end-user, not how you create
them. So from that direction, I'm not sure it would ever make sense for
Policy to require debhelper.
To the extent that Policy already does this in a few places, I think it's
a bug, since among other things it makes it much harder to figure out
what's really going on and it makes it harder for subsequent tool authors.
I agree, the policy should not mandate a tool (because it would be
impossible to experiment *new* and *better* alternatives).
If someone thought there was some much better design for how debhelper
does things and wanted to start from scracth writing a new helper, they
should be able to find documentation explaining what interfaces they need
to satisfy, ideally.
debhelper has a standard interface quite documented in the manpages
(especially when using flat files as input). Anyone could provide an
alternative tool.
And this is a great feature. (anyone trying to do QA on the source will
agree).
The major exception to this right now is that Policy assumes dpkg and the
core dpkg tools
By standardizing more tools, we would be more efficient.
Those tools should be described by their interface, as you mentioned.
(not the dpkg-dev tools necessarily) like dpkg-divert. I
personally think this is a bug and I'd like to see the low-level
documentation of the exact deb format, for instance, in Policy, but it's a
very low priority compared to lots of other Policy work.
Now of course if one orphans one's package or can't maintain it properly
(lots of RC bugs, etc.), then I think redoing the packaging design is fair
game once QA comes into play. Were Manoj to orphan a package, I suspect
it's quite likely that whoever picked it up would convert it to debhelper,
and that's fine. If I adopted a package maintained in bzr, one of the
first things I'd do is convert the VCS repository to Git. But as long as
the package is staying with its current maintainer and that maintainer is
doing a good job, I think the obligation of that maintainer is to satisfy
the interfaces, and what tools they use to do that is their business.
What about Debian users who need to modify a package for special needs?
What about peer review of the packages?
What about other teams in Debian? (nmu, porters...)
What about derivatives?
What about upstream review of his packages? (there isn't just patches).
Debian project raise it's expectation every year (cool). How do we face
the challenge to do more every year? (of course, you could do like the
[French]
Question to all Candidates: we want more, aren't we?
Hello dear candidates, 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? Thanks to each one of you for being candidate. Franklin -- Hints: the obvious leverage are: productivity, quality and count(DD). -- 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/1270108658.3567.722.ca...@solid.paris.klabs.be
Re: Question to all candidates: DPL's role in important package maintenance
On Thu, Apr 01, 2010 at 06:47:53AM +0200, Frans Pop wrote:
Agreed, but would you agree that it is a core part of the role of the
DPL/2IC, or indeed any mediator, to provide at least basic status and
progress info to the project as a whole?
Yes, absolutely. Beside this specific case---which I'm pretty sure
everyone in the project was aware of---we should not assume that the DPL
is aware of all problems like this. The ideal course of actions IMO
should be something like: either proactively or pinged by someone the
DPL is made aware of a problem like this one, he/she tries a mediation
informing the project of the effort, keeps the project posted for a
while, if that fails we fallback to tech-ctte.
I agree with Russ comments on the matter, I think our (as a project)
main responsibility in this specific case has been letting the issue be
delayed this far. I believe that some of the year-old rants on -devel
would have been much more useful if, instead of posting there, people
would have opened an issue to the tech-ctte.
What we've been seeing with this issue is that there has been complete
silence for over three months. I think that a lot of the (heated) public
discussion could have avoided if some progress/status info would have been
provided at regular intervals. In fact, I think that a lot of the public
discussion was as direct result of the total lack of such information.
What are the thoughts of candidates on that?
I completely agree with your analysis on this.
Several of the posts I've seen on -devel were clearly caused by the
frustration of the involved people. Knowing that something was going on
and, even better, being able to *see* what was going on (as it is right
now the case with the -ctte bug log) would have saved quite same flame,
IMHO.
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).
[1] References:
- http://lists.debian.org/debian-devel/2009/12/msg00078.html (+ following)
My comment is in that very same thread already [2] (it is the latter of
your options).
Cheers.
[2] http://lists.debian.org/debian-devel/2009/12/msg00096.html
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Standardization, large scale changes, innovations
Hi,
I think this discussion is beginning to veer off topic, since it
is far from figuring out who to vote for, etc. This is my last post on
ths topic here, if you want to covince me of the error of my ways,
please take it to private email. If you want to change how we do things
to prevent me from doing what I have been doing, please take your pick
-f -devel, -policy, or -ctte.
I also apologize in advance for this email.
On Thu, Apr 01 2010, Frank Lin PIAT wrote:
http://en.wikipedia.org/wiki/Not_Invented_Here -- replace here by ${me}
There isn't just Manoj that work on Manoj's packages (QA team, Security
team, Derivative distro... and our users!). BTW, does Manoj own those
package?. As I wrote those lines, I wonder if some developer don't
precisely use home made stuff to say keep out, this is my own package.
I posit that if you can't figure out my build system, you can't
be very effective about making changes to the package (which is usually
far more complex than my little make files).
A best practice isn't a standard (or a policy), still most people follow
it.
In your opinion, does best equate with popular?
The major exception to this right now is that Policy assumes dpkg and the
core dpkg tools
By standardizing more tools, we would be more efficient.
By that definition, should we not all be working on Windows?
Much more standard than Linux, neh?
What about Debian users who need to modify a package for special needs?
I think if they can modify the software for their needs, they
can modify the build system too. I think my stuff is easier to modify
and propagate than trying to modify debhelper and being able to
distribute the result and having it build on your friends computer
(they need the modified debhelper as well as your modified package, and
that might mess up other package builds for them)
What about peer review of the packages?
My *peers* have no problems dealing with the build system, IMO.
What about other teams in Debian? (nmu, porters...)
I have been packaging for Debian for 15 years now. I don't
recall a concrete instance where this has been an issue.
What about derivatives?
I have heard complaints here, yes, about SELinux packages. I
think the issue was resolved.
What about upstream review of his packages? (there isn't just
patches).
Most upstreams, if they don't use Debian, do not know about
debhelper. At least my packages try to be self contained, and most
upstreams know Make. I think I win this one.
manoj
--
baz bat bamus batis bant. James Troup
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
--
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/87hbnvweqd@anzu.internal.golden-gryphon.com
Re: Question to all Candidates: we want more, aren't we?
On Thu, Apr 1, 2010 at 4:57 AM, Frank Lin PIAT fp...@klabs.be wrote: 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? There are two important things involved: improve our way of working with tools that make it easier to maintain and improve the quality of our packages, and get more people to help us do our jobs. What would you do about it, as a DPL? As I've already said, I will focus a lot on tying to get more people to help Debian, not necessarily through becoming Debian Developers. By being more welcoming towards the help of non-DD contributors, we could recruit the help of more people, thus reducing the current workload on the developers. One important example is fixing bugs. Developers spend quite a lot of time fixing bugs, and most of the time you don't need to be a DD to fix those bugs, anybody can help out fixing more bugs. Another example is the non-code parts of Debian, like documentation or artwork. Most developers don't have enough time for, or maybe just don't care enough about, these areas; we could definitely use the help of people that are not so code-oriented in order to improve the overall Debian experience. In general, the only way to keep up is to recruit more people, and I plan to work on that. -- Besos, Marga -- 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/j2ie8bbf0361004010724qfcfbfbd4u7189479ba90dd...@mail.gmail.com
Re: Questions for all candidates: decentralization of power
On Thu, Apr 01, 2010 at 01:45:45PM +0900, Charles Plessy wrote: 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. I think that what we are doing now puts us in very safe legal ground. I fear what could happen when some litigious copyright holder accuses us of illegally redistributing their software and our reponse is, We just copied it to one other machine so that we could make it available to our entire membership. 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. 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. 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? 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? stew signature.asc Description: Digital signature
Re: Question to all Candidates: we want more, aren't we?
On Thu, Apr 01, 2010 at 11:24:14AM -0300, Margarita Manterola wrote: One important example is fixing bugs. Developers spend quite a lot of time fixing bugs, and most of the time you don't need to be a DD to fix those bugs, anybody can help out fixing more bugs. Another example is the non-code parts of Debian, like documentation or artwork. Most developers don't have enough time for, or maybe just don't care enough about, these areas; we could definitely use the help of people that are not so code-oriented in order to improve the overall Debian experience. Since you bring it up... Simple question: How? (in case it's not clear: since you seem to think it's part of the DPL's responsabilities, how do you plan to attract people to help with these things?) Marcelo -- 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/20100401155052.ga32...@esk
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 to all Candidates: we want more, aren't we?
On Fri, Apr 02, 2010 at 01:34:02AM +0900, Charles Plessy wrote: 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. Meaning what, precisely? -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied twisted, Just an earth-bound misfit, I... -- 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/20100401165913.gb7...@einval.com
Re: Question to all Candidates: we want more, aren't we?
On Thu, Apr 1, 2010 at 12:50 PM, Marcelo E. Magallon mmaga...@debian.org wrote: Simple question: How? (in case it's not clear: since you seem to think it's part of the DPL's responsabilities, how do you plan to attract people to help with these things?) I do not think it's part of the DPL responsibilities. I do think that it's something that Debian needs and that doing it with the DPL hat on is going to make it easier, it's not a requirement (most stuff that DPL candidates list as stuff they'd like to do, do not *require* being DPL, but it helps) I've stated some hows on my platform and on other mails during the campaign. There are many things that could be done, here is a small list that could grow larger: -*- For bugs/package contributors: * Have a constant contest of bug-fixer-of-the-month and bug-reporter-of-the-month. This means listing people and the bugs they fixed and/or reported (I consider reporting GOOD bugs a very important task for a good release). If possible, give the winners of each month some prize (t-shirt, mug, etc), if not possible, at least list them in a hall of fame page. * Have two separate How to help web pages, one for DDs and one for non-DDs, where all teams can list the tasks that they need help with and how to accomplish them. Give these pages as much visibility as possible. For artists: * Have some centralized place where artists can contribute their designs and where users can get those designs to have a cooler look on their Debian system. * Give more recognition to artists that contribute to make Debian Art. Maybe even @debian.org address and the right to vote, to the ones that are committed to Debian. For documentators / translators: * Give more recognition to the work done, as in @debian.org address and the right to vote in elections, even if no package upload rights are given. For everybody: * Make a Debian/Rules campaign, with web-banners (for blogs and the like), t-shirts, and as many other merchandise as can be imagined, aiming to replace the image that Debian is too difficult. -*- These are just some scattered ideas, I'm sure that many more good ideas are floating in other people's minds, and if I'm elected I'd be happy to apply them as well. The important point is to really focus on reaching out and make Debian more welcoming towards more people. -- Besos, Marga -- 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/v2ke8bbf0361004011100y237ae384x491876d6a4e53...@mail.gmail.com
Re: Standardization, large scale changes, innovations
On Thu, Apr 01, 2010 at 05:15:38AM -0700, Manoj Srivastava wrote: What about peer review of the packages? My *peers* have no problems dealing with the build system, IMO. As long as you tautologically define your *peers* as the set of people willing to tolerate the gratuitous overhead of learning an idiosyncratic build system when they could be getting on with the real work of fixing bugs instead, yes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Question to all Candidates: we want more, aren't we?
On Thu, Apr 01, 2010 at 03:00:29PM -0300, Margarita Manterola wrote: I do not think it's part of the DPL responsibilities. I do think that it's something that Debian needs and that doing it with the DPL hat on is going to make it easier, it's not a requirement (most stuff that DPL candidates list as stuff they'd like to do, do not *require* being DPL, but it helps) IMO many people, including myself and other DPL candidates, agree with you regarding that this is something that Debian would benefit from. And as you point out, you don't need DPL status to do it. You say it would be easier if you were DPL. Why do you think this is the case? Put in a different perspective, of the things you mention, what's harder to do (and why) if you don't have DPL status? The questions are not purely rethorical: I do believe you are identifying a larger and more complex issue within Debian, one where there's — from my POV — no agreement about whether or not it is an actual *problem* in the organization and if it is, what the solution looks like. (and yes, you could argue that I'm bordering on the question of what do we need a DPL for, but I don't really want to go there) If we agree that these tasks do not need DPL status, and if you are *not* elected DPL, will you try to push forward the things you mention? * Have a constant contest of bug-fixer-of-the-month and bug-reporter-of-the-month. This means listing people and the bugs they fixed and/or reported (I consider reporting GOOD bugs a very important task for a good release). If possible, give the winners of each month some prize (t-shirt, mug, etc), if not possible, at least list them in a hall of fame page. Just for the record, I think this is a very slippery slope. Thanks, Marcelo -- 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/20100401185218.ga2...@esk
Re: Questions for all candidates: decentralization of power
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). If there is ever any legal fun around this, it is a *HUGE* difference if you can say Only people who really have need have access before the check is finished or Everyone who feels like it and happens to be a DD at that time has access. 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. And on what base do you ground that? -- bye, Joerg Maybe, just once, someone will call me 'Sir' without adding, 'You're making a scene.' -- 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/87mxxnufdb@gkar.ganneff.de
Re: Question to all Candidates: we want more, aren't we?
On Thu, Apr 1, 2010 at 3:52 PM, Marcelo E. Magallon mmaga...@debian.org wrote: You say it would be easier if you were DPL. Why do you think this is the case? It is inevitable that people will take you more seriously when you are the appointed leader than if you are just a random developer. But also, the ability to delegate someone to do something, which is one of the few things that DPL can actually do, could help into establishing the different teams that would have to be put together. Put in a different perspective, of the things you mention, what's harder to do (and why) if you don't have DPL status? Many of those tasks could be done by anybody. Doing them all at once is not possible, because time is finite. So, by being DPL, I could delegate to the right teams to get the tasks done. By being just one more DD, I'd have to choose one project and do only that one. Changing the way we handle membership (that I listed as a possible way to reaching more people) is something that is *not* part of my DPL plans, it requires going through a GR that I think should be pushed by the appropriate people (DAM and FD). The questions are not purely rethorical: I do believe you are identifying a larger and more complex issue within Debian, one where there's — from my POV — no agreement about whether or not it is an actual *problem* in the organization and if it is, what the solution looks like. Uhm, I think that the lack of enough people is an identified problem by most of the developer community. The ideas on how to fix this lack of enough people may vary, but fact that we need to somehow get more people to help I think it's pretty established. (and yes, you could argue that I'm bordering on the question of what do we need a DPL for, but I don't really want to go there) We need the DPL to lead. It's not possible for one person to do everything, we need a leader that manages to get the developers to work together on common goals, so that it's not just a one-person-show, but a project-wide-effort. If we agree that these tasks do not need DPL status, and if you are *not* elected DPL, will you try to push forward the things you mention? I'm not sure. if I am not elected DPL, most probably I will devote as much time as possible on getting squeeze ready for release. But I might try to get the ball rolling for one or two of the ideas listed in my platform. * Have a constant contest of bug-fixer-of-the-month and bug-reporter-of-the-month. This means listing people and the bugs they fixed and/or reported (I consider reporting GOOD bugs a very important task for a good release). If possible, give the winners of each month some prize (t-shirt, mug, etc), if not possible, at least list them in a hall of fame page. Just for the record, I think this is a very slippery slope. I'm not sure why you think so, but I do acknowledge that this is a hard thing to implement. I'd like this contest to be fair and to be above all about making Debian better, not about personal glory, some limitations would need to be implemented so that nobody tries to abuse it. However, if there are well kept rules, I think that it could mean quite a lot of motivation for a lot of people. I'm open to suggestions on how to make this better and less slippery. -- Besos, Marga -- 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/o2me8bbf0361004011439k9554c50cy61fae1579a353...@mail.gmail.com
Debian Project Leader Elections 2010: Call for votes
Hi, This is the first call for votes for the Debian Project Leader Elections 2010. Voting period starts 00:00:00 UTC on Friday, April 2nd, 2010 Votes must be received by 23:59:59 UTC on Thursday, April 15th, 2010 This vote is being conducted as required by the Debian Constitution. You may see the constitution at http://www.debian.org/devel/constitution. For voting questions or problems contact secret...@debian.org. The details of the candidate platforms can be found at: http://www.debian.org/vote/2010/platforms/ Also, note that you can get a fresh ballot any time before the end of the vote by sending a mail to bal...@vote.debian.org with the subject leader2010. HOW TO VOTE First, read the full text of the platforms and rebuttals. To cast a vote, it is necessary to send this ballot filled out to a dedicated e-mail address, in a signed message, as described below. The dedicated email address this ballot should be sent to is: leader2...@vote.debian.org The form you need to fill out is contained at the bottom of this message, marked with two lines containing the characters '-=-=-=-=-=-'. Do not erase anything between those lines, and do not change the choice names. There are 5 choices in the form, which you may rank with numbers between 1 and 5. In the brackets next to your preferred choice, place a 1. Place a 2 in the brackets next to your next choice. Continue until you reach your last choice. Do not enter a number smaller than 1 or larger than 5. You may skip numbers, leave some choices unranked, and rank options equally. Unranked choices are considered equally the least desired choices, and ranked below all ranked choices. To vote no, no matter what, rank None Of The Above as more desirable than the unacceptable choices, or you may rank the None Of The Above choice and leave choices you consider unacceptable blank. (Note: if the None Of The Above choice is unranked, then it is equal to all other unranked choices, if any -- no special consideration is given to the None Of The Above choice by the voting software). Finally, mail the filled out ballot to: leader2...@vote.debian.org. Don't worry about spacing of the columns or any quote characters () that your reply inserts. NOTE: The vote must be GPG signed (or PGP signed) with your key that is in the Debian keyring. You may, if you wish, choose to send a signed, encrypted ballot: use the vote key appended below for encryption. The voting software (Devotee) accepts mail that either contains only an unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail (RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME. - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 7efb5344-bc61-46d2-b86c-3d1b144e1236 [ ] Choice 1: Stefano Zacchiroli [ ] Choice 2: Wouter Verhelst [ ] Choice 3: Charles Plessy [ ] Choice 4: Margarita Manterola [ ] Choice 5: None Of The Above - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- The responses to a valid vote shall be signed by the vote key created for this vote. The public key for the vote, signed by the Project secretary, is appended below. Kurt Roeckx Debian Project Secretary -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.10 (GNU/Linux) mQINBEu0/IEBEAC3hkrYIg4JiL1IdwggsUZue6m171SNUH1brjAxndMXoNLwGgin kFIre4lIR0jYcycepKVldCL2RQ6oSvCFydvmEeSlS16EBs8IPKqK3rRLaMHZFoPj g2+N0Gvysyj60w4rCHq2fQL25h2cSZqrjXS6OLV4Tp5jPbIS25ChHwurPAktc4u8 L2Youho8dXCvZ67Kh0jpNShyVeOmcBY3xLfzjwqowe5PiXlamV2EMue46oRase4r 4fD47g+F6zu1S4+E8gmhELfHvAkzJ7k/UBnVBufZQb2R7BVkpIJxXNOh98g9r6dt V7GPqFaoQrJ210tRXygdUEVMamGv7SOwQkWfsVgTc5adigFrgwqd5+hC4PNoANVy LC/6KHmShPo6Gl29lvA+8VsZlH3dS0Aex8akEZngTqvgDimcx4XgzhWo/Jwy2uTl bZwQQu3YIBdz7btMpaN9IdCFMEJnEuka1HEreY7SpbNdxb0z1UMwI2TlDHFvR1Hh iDYniNpf8H6sQHQ3DXVOpptuys3NZMSKzyysNbLpbd2INPVDfIgnS6nneshTc1xD bmRkg9Gy/dgFmo2/0PeX6F/cEJlnOiO+EohzFfJSrKJI+roZVWW1SlHh5XwYjyMK bvVSlOrPPN0vK31a1Qdxo8Bvf+qRxIzO/UKLrLXeUi+zsp0TajuNmJApfwARAQAB tCpEUEwgdm90ZSAyMDEwIDxsZWFkZXIyMDEwQHZvdGUuZGViaWFuLm9yZz6JAj0E EwEKACcFAku0/IECGwMFCQAWaYAFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQ wASq4F9uido4PQ/+KQ+M7LZ+pChKZn2fZkSjJgxxXjI5Rog5mewRCxGxHJMBZvwj pEYJrSgGx/afKfsLZtQ5TGVzN+t6R13tdLgxPxD8xOxKDB0Snoj4bglA8/ja8GSn 9LpGSxFGLnATDasddax5KGrThZn/pnaIZUNtuo7KlPCTPQuxQMqbb/aylCbyyPpk 9Mkyv2D+nOEAqHb71acZFzaEkBGMzbCm4VFANh5rPNA3DzRShQoXLMsNV/Yih2JO SpyYQfcfZib+xs40+qVQZDG5NB/swbdc2HVYbH0ci8c1GjLP8Cg4Hb5mRh7C3PFL /lULbjWi7p88VfPMtD+j5ImONno7A0qAtjH7sT+HTLnJTqWPAxyvzy4uCbNPh4+N DibwN4a8E4gX0G7g4YtZDeZaDz9XtTDxoJCIa9aKKbl/31Vd4vhoNHfxJYTAvP66 0NAVrnrAte8Kzuy8iqNej9QoDLDDWCjEjE9hX0UAaS0lCvAHdYUjFe05eNSzJXPG qfxEJ2PnFf61kWlPnJbbfN5G7vJLmk2EvvqMueCgDQ2233LWzJFnS0fB23UHRXUp mLJtGDaRvXKbV5iHDcQORM0QpFze333IFJlbymarivW+kiChYLSSIlBrR+3xYNhs UlKSxpKZlAEmDRUhsMYGgwli8oddPVtO2kgjk/jYbL5n8fWSWeSGvdvWb6qIRgQQ
Re: Debian Project Leader Elections 2010: Call for votes
Debian Project Secretary - Kurt Roeckx secret...@debian.org writes: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 7efb5344-bc61-46d2-b86c-3d1b144e1236 [ 1 ] Choice 1: Stefano Zacchiroli [ 2 ] Choice 2: Wouter Verhelst [ 5 ] Choice 3: Charles Plessy [ 3 ] Choice 4: Margarita Manterola [ 4 ] Choice 5: None Of The Above - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- Rémi Vanicat pgpZyQC8771tP.pgp Description: PGP signature
