Re: Question for all candidates: Release process
Reading Wouter's post in this thread just now I realize I made a fairly stupid mistake when writing my mail. Frans Pop wrote: > This seems to be what the RT has been focussing on after Sarge. [...] s/Sarge/Etch/ > During the Sarge release these two sides were in balance. After that, for > Sarge stable releases and the Lenny release, [...] s/Sarge/Etch/ -- 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/201003160723.26265.elen...@planet.nl
Re: Question to all Candidates: Project Funds and donations
On Tue, Mar 16, 2010 at 5:45 AM, Wouter Verhelst wrote: >> b) What qualifies a contributor to become a "Debian Partner"? What >> qualifies a "Debian Partner"? > > I don't think we have a formal list of "Debian Partners" (but I could be > wrong). I'm also not convinced we need one. > > If we do have such a list that I'm not aware of, it might be a good idea > to see if it's working well. I don't think I'll be working much in this > area, however. http://www.debian.org/partners/ -- bye, pabs http://wiki.debian.org/PaulWise -- 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/e13a36b31003152037v11f52c2ft1c9dc7765e7da...@mail.gmail.com
Re: Question to all Candidates: Heated discussions
On Tue, Mar 16, 2010 at 12:11:39PM +1100, Ben Finney wrote: > Wouter Verhelst writes: > > > On Sun, Mar 14, 2010 at 02:40:32AM +, Dmitrijs Ledkovs wrote: > > > Do you think current frequency/amount of heated discussions is > > > acceptable for the Debian project? > > > > I believe no amount of ad-hominem discussion is acceptable. > > There's a significant difference between ad hominem discussion (which I > interpret as meaning “discussion about a person”) versus argumentum ad > hominem (the widely-used but sometimes poorly-understood logical > fallacy http://www.fallacyfiles.org/adhomine.html>). I meant 'ad hominem attacks', rather than 'ad hominem discussion'. I.e., you're making the discussion personal, rather than about the technical matter you're supposedly talking about. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Invite to join the Release Team
On Sun, Mar 14, 2010 at 06:14:45PM +, Clint Adams wrote: > On Sun, Mar 14, 2010 at 04:09:34PM +0100, Frans Pop wrote: > > That meeting took place in May of last year. What's the point of discussing > > it almost 9 months later? What exactly triggered your blog post? > > We are in an election period and I would like for the project > to elect a DPL who not only does not support a certain level > of non-transparency, but is actively intolerant of it. If you have such questions, it's usually easiest for everyone involved if you bring them up on -vote, the relevant forum for this kind of thing. Anyway, since you ask (cc to -vote added), I believe it is nobody's business where anyone heads off to if they pay for it all by themselves. If a group of Debian people decides to meet up in a pub in Cambridge, that's their prerogative. If the members of that group just happen to coincide with the members of a particular team within Debian, that does not change the situation, nor would it if they discuss matters related to what the team does in Debian; and if those discussions result in any kind of decision that is their responsibility to take, I still don't see any problem. Whether we talk about the release team consisting of people from all over the world, or the debian ocaml team consisting of mostly people from France (with the occasional Italian guy -- hey Zack!) is irrelevant in that part, IMO. Of course it is desirable for the team to communicate any decisions through the proper channels, whenever and wherever they could be relevant to other people; this may involve a debian-devel-announce post, or, say, in case of something relevant to porters, a mail to the debian-ports alias. The team should also be careful to talk to relevant other people *before* making a definite decision if it could reasonably be expected that such input from outside the team could bring up important information. But all this is no different to any other form of communication. As long as a team does not actively refuse cooperation from people outside their team, it should be totally their decision whether they want to use mailinglists, private mails, IRC channels, blog posts, instant messaging, or real-life meetings as their preferred method of communication. Of course, if the team does ask for (and receives) Debian money, then some level of reporting after the fact should be mandatory, to make sure that the DPL and the project as a whole can decide whether the money has been well spent. It should also be made reasonably clear how interested parties can join the team. But beyond that, I do not believe that any requirements should be made on how people decide what their preferred method of communication is. > I do not know whether or not we have any potential candidates > who fit that bill yet. Hope this helps, -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Question to all Candidates: Heated discussions
Wouter Verhelst writes: > On Sun, Mar 14, 2010 at 02:40:32AM +, Dmitrijs Ledkovs wrote: > > Do you think current frequency/amount of heated discussions is > > acceptable for the Debian project? > > I believe no amount of ad-hominem discussion is acceptable. There's a significant difference between ad hominem discussion (which I interpret as meaning “discussion about a person”) versus argumentum ad hominem (the widely-used but sometimes poorly-understood logical fallacy http://www.fallacyfiles.org/adhomine.html>). The only case where ad hominem discussion qualifies as the argumentum ad hominem fallacy is when it is used as a red herring; i.e. when the personal details being discussed are irrelevant to the substance of the argument. Could you clarify what you mean by your statement above in light of that difference? -- \ “I used to be an airline pilot. I got fired because I kept | `\ locking the keys in the plane. They caught me on an 80 foot | _o__)stepladder with a coathanger.” —Steven Wright | Ben Finney pgpKfEMjGDJsT.pgp Description: PGP signature
Bug#574059: Provide link to SPI meeting minutes and/or treasurer reports in appropriate (TBD) location
Package: debian-www Severity: wishlist On Tue, 16 Mar 2010, Stefano Zacchiroli wrote: > On Mon, Mar 15, 2010 at 11:13:02PM +0100, Martin Zobel-Helas wrote: > > SPI's Treasurer, Michael Schultheiss, (and by the way Debian Developer) > > does a really good job by sending out monthly Treasurer's Reports which > > are in every monthly meeting minutes linked from > > http://www.spi-inc.org/corporate/meeting-minutes > > That, together with the fact that I can't find any reference to that > link on *.debian.org, is why I thought it was not public. I believe > a lot of other DDs do not know about that link, in fact a couple of > people which asked me my draft platform stared at my gross figure of > Debian total money and asked me « are you sure this information is > public? ». I honestly never thought about it myself, but it's fairly trivial to file a bug asking for it (and someone who has a better idea than I do right this second of where it should go could even prepare and/or commit a patch. Don Armstrong -- She was alot like starbucks. IE, generic and expensive. -- hugh macleod http://www.gapingvoid.com/Moveable_Type/archives/001376.html http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20100316005848.gz4...@teltox.donarmstrong.com
Re: Question to all candidates: financing of development
On Mon, Mar 15, 2010 at 04:53:20PM -0700, Steve Langasek wrote: > On Tue, Mar 16, 2010 at 12:12:02AM +0100, Wouter Verhelst wrote: > > I also don't think it is a bad thing, in principle, if Debian were to > > pay people to work on Debian. However, it is generally a bad idea if > > some cabal were to select who could get Debian monies and who couldn't; > > I believe that is the main problem that existed with the Dunk-Tank > > story. > > The use of Debian money for Dunc Tank was only present in a first draft that > was discarded in the face of opposition within the project. Does the final > funding solution that was implemented also fall under this "cabal" > description, in your opinion? It was a bit of a gray area. On the one hand, the final funding solution was open, did not in theory limit who could benefit from the set-up, and was not strictly related to Debian. On the other hand, it was a fairly logical continuation of what could be considered as such, and I feel more effort could have been put into engaging with the community to work out bad feelings than has been done. For the record, I did second the original unamended text for 2006_006, the 'Re-affirm support to the Debian Project Leader' vote, which had the phrase 'The Debian Project does not object to the experiment named "Dunc-Tank", lead by Anthony Towns, the current DPL, and Steve McIntyre, the Second in Charge' in it, and I would do so again if the situation were to repeat itself. [...] > If not, how do you reconcile this with the ongoing community > resistance to Dunc Tank even after it was decoupled from Debian money? I believe that many (though certainly not all) people who were still resistant against Dunc Tank after its decoupling from Debian money, would not have rejected the idea had it been proposed the way it was eventually implemented from the start. However, by the time the decoupling had happened, a rather large flamewar was already going on, and many people failed to rationalize by that time what was happening, instead reacting more emotionally. I can of course not speak for the whole community, however; this is just how I perceive that things happened. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Question for all candidates: Care of Core infrastructure
On Mon, Mar 15, 2010 at 11:30:39AM +0100, Marc Haber wrote: > This is for all candidates. > > 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. I am not saying that noone seems to care, but > I see a lot of annoying issues not being addressed. > > An totally incomplete list: [...snip examples...] > Do you see the diminishing care for our Core infrastructure as a > problem? Yes. I point to this very problem in my platform (though I give different examples, the points are basically the same). But I believe the problem is wider than just the core infrastructure; it is about the project as a whole facing competition for attracting distribution developers by the fact that there are several other community-based distributions out there today than there were about a decade ago. The numbers are easy. The amount of Debian Developers has been approximately steady at about 1000 for the past ten years. Over that same time, the amount of packages in our distribution has been steadily increasing. By definition, that means the ratio of Debian Developers per package has been doing down, and thus also that the core infrastructure has less contributors. Having more packages does not necessarily mean that only fringe packages are added; useful new software is written all the time, and the fact that useful new software is written does not make useful old software disappear. I believe the problem is not that less people are interested in Debian's core infrastructure; the problem is that less people are interested in *Debian*. We need to work on that. As we say in Dutch, "stilstaan is achteruitgaan" -- "standing still is the same as going backwards" -- and the number of DDs has not been going up for quite a while now. > 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? Given the above, I believe the most important task ahead of us is making Debian more attractive for users and prospective contributors; that is what I intend to work on. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Will you withdraw delegations of DD not behaving correctly?
Hi, On Mon, Mar 15, 2010 at 08:13:23AM +0100, Raphael Hertzog wrote: > Hello, > > another question to all candidates (this question is inspired by a recent > event). Could you comment on what event, exactly, you are talking about? (Don't feel too compelled to if you believe this would unnecessarily hurt the privacy or reputation of the people involved...) > Most of you have answered that it's not possible to regulate the heated > discussions but it's possible to set a good example. If only the leader > behaves properly, it will still be difficult to make the climate change. > But if all the delegates behave properly, and if delegates that do not > behave properly are withdrawn due to this, we might get better results. > > 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? I do not believe that punitive measures are the best way to react to socially unacceptable behaviour, except in extreme circumstances (i.e., multiple unrelated events that show that a particular delegate is exhibiting socially unacceptable behaviour). What you do if you do that, is to basically say "be nice, or else *I*'ll be not nice", which is a perfect way of risking to exhibit socially unacceptable behaviour yourself (unless you're perfect, but I don't believe in perfection). I also believe that people, when told in a polite way that they are being rude, will often apologise or clarify what they meant. A good example is the recent set of blog posts by Thorsten Glaser on Planet Debian, who retracted some of his statements after being challenged on his behaviour by several people. So, no, I think it's quite unlikely that I'll have to resort to doing that; but if necessary, I will not refuse to do so. > 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? The best way to come up with a working code of conduct, IMO, is to breed a set of unwritten social rules that people know they should not violate too easily, because they'll get publically challenged on that behaviour. Of course some people will just ignore the social rules anyway, even when politely challenged by several people; but the listmasters commonly already ban such people, and that works well. Having a formal code of conduct will just invite lawyering and more proceduring by trolls who simply wish to make our lives miserable. I do not believe it serves any useful purpose. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Question to all candidates: financing of development
On Tue, Mar 16, 2010 at 12:12:02AM +0100, Wouter Verhelst wrote: > I also don't think it is a bad thing, in principle, if Debian were to > pay people to work on Debian. However, it is generally a bad idea if > some cabal were to select who could get Debian monies and who couldn't; > I believe that is the main problem that existed with the Dunk-Tank > story. The use of Debian money for Dunc Tank was only present in a first draft that was discarded in the face of opposition within the project. Does the final funding solution that was implemented also fall under this "cabal" description, in your opinion? If so, how do you distinguish this from other DDs who are privately funded to work on Debian? If not, how do you reconcile this with the ongoing community resistance to Dunc Tank even after it was decoupled from Debian money? -- 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 -- 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/20100315235320.gb21...@dario.dodds.net
Re: Question for all candidates: Release process
On Mon, Mar 15, 2010 at 08:09:19AM +0100, Lucas Nussbaum wrote: > On 14/03/10 at 14:44 -0700, Russ Allbery wrote: > > This is for all candidates. > > > > 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. There's usually always at > > least some frustration, anger, and upsetness, and there seems to usually > > be at least one resignation over the course of a release, often in a way > > that hurts other activities in Debian for a time. > > > > Do you have any ideas how, as DPL, you would (or even could) address this? > > I'm personally the most concerned with the social issues. A delayed > > release can be frustrating but doesn't have that much negative impact, but > > volunteers with enough knowledge of Debian to be able to serve as release > > managers or helpers are rare. And usually the arguments not only hurt > > their contributions to Debian but usually hurt the contributions to Debian > > of the people on the other side of the argument as well, who are often > > also valuable and difficult-to-replace volunteers. > > > > Do you have any thoughts about how to resolve release issues with less > > hurt and negative impact to the project all around? > > Three more release-related questions. > > 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? From my perspective, it looks like some people jumped the gun a little, though with the best of intentions. > - 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? I don't think it hurts anyone for Debian to cooperate with another project, be that project Ubuntu, the FSF, or something else. If the cooperation with Ubuntu worked well for this release (I am not very up-to-date on the details here), then I see no reason why we should not do so. > - So, we are now in March. What is your opinion with the release process > so far? When do you see the release happening? In my opinion, the best release we ever had (that I was a part of, at least) was the Etch release process; shortly after Sarge had been released, the release managers had started to regularly update the project as a whole on where we were in the process, and I believe that worked very very well. During the whole of the Etch release process, there was never really a point in time where I felt I didn't know how far away the release still was. It feels to me as though the frequency and/or quality of updates has reduced somewhat since the Etch release, though I'll readily admit that that is just a gut feeling. At any rate, I do not feel I am as up-to-date as I was during the Etch release process on when the release is going to happen. I don't think it's going to take more than, say, half a year, though. > (I'm fully aware that the DPL is not in a position to take many actions > regarding the release. However, similar questions are likely to be asked > during post-election interviews, so we would better know how you will > answer ;) Hope that answers that, -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Question for all candidates: Release process
On Sun, Mar 14, 2010 at 02:44:15PM -0700, Russ Allbery wrote: > This is for all candidates. > > 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. There's usually always at > least some frustration, anger, and upsetness, and there seems to usually > be at least one resignation over the course of a release, often in a way > that hurts other activities in Debian for a time. I believe social issues are the main problems Debian is still facing at this time, not just in the release process. > Do you have any ideas how, as DPL, you would (or even could) address this? > I'm personally the most concerned with the social issues. The social issues in our community are self-enforcing. That is, if it is accepted that people are rude, then there is nothing you can really do about repetitive rudeness towards your person, beyond resigning. However, if we, as a project, decide that no, rudeness and ad-hominem attacks are not acceptable, then such things will not go unnoticed. As a DPL, I will promote, in whatever way I can, to publicly (but politely) disapprove of what should be unacceptable behaviour; but also to allow people to make mistakes. > A delayed release can be frustrating but doesn't have that much > negative impact, but volunteers with enough knowledge of Debian to be > able to serve as release managers or helpers are rare. And usually > the arguments not only hurt their contributions to Debian but usually > hurt the contributions to Debian of the people on the other side of > the argument as well, who are often also valuable and > difficult-to-replace volunteers. Indeed. I use a different wording, but basically outline the same thing in my platform, and I believe it is the single most important problem Debian is facing currently. Finding volunteers is hard; keeping them is even harder. If we do not have a welcoming community, then we drive people away, and we should not do that. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Question to all the candidates: communication
On Sun, Mar 14, 2010 at 10:17:06AM +0700, Paul Wise wrote: > Dear candidates, > > Debian has a lot of project communications media; lists, forums, IRC, > planet, bts, RT. There are also a lot of external communications media > covering Debian; news media, , social networks, blogs, microblogging > sites & non-IRC chat, video sites and so on. > > Which project and external Debian-related communications media do you > follow? I follow several mailinglists (some in what could be considered a lurking mode, some more actively), the blogs on Planet Debian, and I am reasonably active on a number of IRC channels on both OFTC and freenode. As for external channels, I tend to read LWN infrequently; and when someone posts a link to some news article related to Debian through some other communication channel, I often read that, too, but I don't go actively hunting for such articles. I usually find that external communication about Debian, when not actively pursued, does not tell me things I do not already know. > and contribute to? My blog is on Planet Debian, and though my blogging frequency has reduced, I still consider myself a somewhat active blogger. I don't believe in microblogging, and am offended by Facebook's excuse for a "privacy policy", so don't go there either. > 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). Phew. Are you sure? That list is rather long, and would get dull rather quickly. If you really must know, most of that information isn't private, anyway. For the IRC channels, there's the "/whois" command, that (at least on OFTC, not sure about other networks) will tell you what channels I'm on. For mailinglists: I usually do post to lists that I'm subscribed to, though not always as frequently. I rarely unsubscribe from a list, though it does happen on the more active lists that I only manage to mark as read once in a blue moon. I don't do forums; they just don't work for me. > How do you see those two lists changing if you become DPL? Not by much; there will just be more mails, and probably some more lists that will go in lurking mode (though not too many, I hope). > Which of these communications media do you feel is important for the > DPL to read? Since the official communication channel within Debian is email, I believe that should be the only bits that are *important* for the DPL to read. Anything else is good, but not necessary. > Please breifly comment on how you see Debian's relationship with some > of these media. Debian is mail. Period. If you don't have mail, you can't do Debian. Planet Debian has a semi-official status. That is, often there's interesting bits of news posted there, but it shouldn't contain important bits of information -- those should be on the one and only required mailinglist. IRC, to me, is just a way to relax and to get quick help on some matters. Since there is an 'irc.debian.org' alias, it's probably fair to say that the channels are official, too; but as an immediate medium, its usefulness for important bits of information is limited. Web forums are useful to a particular subset of Debian users that I do not consider myself to be part of. I think we should continue to provide them if we can fix the issues we seem to be having with them currently, though I do not have good suggestions on how to do that. External media of course aren't something Debian has an influence over, and that's a good thing. > Do you feel any of these media have been misused by Debian people > (DDs/non-DDs alike)? If so, what action would you take if you become > DPL? No. Occasionally, announcements have been made over the wrong channel that should instead have been made to debian-devel-announce; but when challenged on that, people usually submit them to the right forum. > Do you feel the general tone and perception of Debian is positive on > the media that you follow? What action would you take to improve these > if you become DPL? This differs from medium to medium. I have some more details on what I plan to do in my platform; if you have some more questions on that after it has been published, I would be happy to answer them. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Question for all candidates: Care of Core infrastructure
On Tue, Mar 16, 2010 at 12:04:57AM +0100, Cyril Brulebois wrote: > Marc Haber (15/03/2010): > > Maybe we failed to provide such a "two-liner", which in fact is, > > unfortunately, much more complicated than one might think naively. > > Additionally, example code for policy-rc.d is (almost?) nonexistent. > > Maybe running reportbug would be more efficient than talking about it > on -vote@, don't you think? Like #452645 ? Mike -- 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/20100315230945.ga9...@glandium.org
Re: Question to all Candidates: Heated discussions
On Sun, Mar 14, 2010 at 02:40:32AM +, Dmitrijs Ledkovs wrote: > Hello =) > > Sometimes technical Debian discussions (mailing lists, bug reports, > blog posts, etc.) become personal flame-wars. Indeed. > Do you think current frequency/amount of heated discussions is > acceptable for the Debian project? I believe no amount of ad-hominem discussion is acceptable. I do believe heated arguments are acceptable, but it should not go personal; i.e., the difference between "this is a silly argument, because " and "don't be silly". > What would you do to reduce those? I go into that in quite some detail in my platform. To summarize: I encourage people to (politely) challenge people on what should be unacceptable behaviour but (in our community) isn't, yet, and will do so myself. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Question to all Candidate: In ten years...
On Sun, Mar 14, 2010 at 02:35:28AM +, Dmitrijs Ledkovs wrote: > Hello =) > > Please finish "In ten years I'd like Debian" ...to still be the distribution I consider to be the best one out there. It is today, has been for the past nine years, and it would be a shame if I found myself moving to something else because Debian's quality had declined. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Question to all candidates: financing of development
Hi Raphael, On Sat, Mar 13, 2010 at 08:18:00AM +0100, Raphael Hertzog wrote: > Hello, > > this is a question to all DPL candidates. > > 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 > > What advice would you give her? A very good question; thank you for giving me the chance to reply to it. Let me first say that I do not think it is a bad thing that some people get paid to work on Debian while some others don't. That's a perfectly normal thing; some people like Debian so much that they don't want to do anything else, others see Debian just as a hobby, which they'd lose if they'd get a job that involves Debian. I also don't think it is a bad thing, in principle, if Debian were to pay people to work on Debian. However, it is generally a bad idea if some cabal were to select who could get Debian monies and who couldn't; I believe that is the main problem that existed with the Dunk-Tank story. > What other pitfalls from Dunc-Tank must she pay attention to? Not sure. > Do you have concrete suggestions for her on how it should be working? I know that the FreeBSD community has experimented with paid development for FreeBSD in the past; the first such attempt was done by Poul-Henning Kamp[1]. AIUI, the model they have used goes something like this: - Some FreeBSD developer decides to do sponsored development. This developer announces that fact, states the areas that the sponsored development will be about, an amount of money that would be required for the plan to go through, and asks for sponsorship pledges. - People with an interest in the things this developer intends work on pledge monies. There have been people who pledged as little as one euro, and companies who pledged several tens of thousands. - If the amount of community pledges seem reasonable enough and, in the judgement of the people in charge of the FreeBSD foundation (which holds monies in trust for FreeBSD), the cause is worth it, then monies may be pledged to the cause by the foundation as well. > Would you encourage her to go forward or would you try to convince her to > forget this idea? I believe the FreeBSD model keeps a good balance between spending money on causes that benefit the project on the one hand, and not being too cabalistic on the other, and would encourage anyone who wants to attempt something similar in Debian. I do not plan to actively pursue this myself, however. I don't think having some "infrastructure" for sponsored development within Debian is a good idea. [1] http://people.freebsd.org/~phk/funding.html -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Question to all Candidates: Project Funds and donations
On Mon, Mar 15, 2010 at 11:13:02PM +0100, Martin Zobel-Helas wrote: > SPI's Treasurer, Michael Schultheiss, (and by the way Debian Developer) > does a really good job by sending out monthly Treasurer's Reports which > are in every monthly meeting minutes linked from > http://www.spi-inc.org/corporate/meeting-minutes Oh, interesting. I agree that Michael does a wonderful job with the monthly Treasurer's Reports, I've been following reports for the past 3 years. Problem is: I've always seen the reports only posted to the spi-private mailing list, which is not accessible to non subscribers (and to subscribe you must be a SPI member). That, together with the fact that I can't find any reference to that link on *.debian.org, is why I thought it was not public. I believe a lot of other DDs do not know about that link, in fact a couple of people which asked me my draft platform stared at my gross figure of Debian total money and asked me « are you sure this information is public? ». But OK, I take that back for what concerns SPI, it was just my ignorance. It does not solve the problem of getting in a prominent, visible, and central place all the accounting of Debian money, though. Fixing that should start with appointing a new Debian Auditor, as discussed with/by Kalle in this thread. Cheers. -- 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: Question for all candidates: Care of Core infrastructure
On Tue, Mar 16, 2010 at 12:04:57AM +0100, Cyril Brulebois wrote: > Marc Haber (15/03/2010): > > Maybe we failed to provide such a "two-liner", which in fact is, > > unfortunately, much more complicated than one might think naively. > > Additionally, example code for policy-rc.d is (almost?) nonexistent. > > Maybe running reportbug would be more efficient than talking about it > on -vote@, don't you think? Such as #452465, filed in November 2007? Remember, this is about manpower. Not about bugs rotting away in the BTS because nobody cares to fix them. Having invoke-rc.d implemented in at least two different package doesn't make finding the right place for docs any easier. But this was only one of an incomplete list of examples. There is no need to brag about this one. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- 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/20100315230851.ge32...@torres.zugschlus.de
Re: Question for all candidates: Care of Core infrastructure
Marc Haber (15/03/2010): > Maybe we failed to provide such a "two-liner", which in fact is, > unfortunately, much more complicated than one might think naively. > Additionally, example code for policy-rc.d is (almost?) nonexistent. Maybe running reportbug would be more efficient than talking about it on -vote@, don't you think? Mraw, KiBi. signature.asc Description: Digital signature
Re: Question to all the candidates: time
On Sat, Mar 13, 2010 at 12:56:17PM +0700, Paul Wise wrote: > #include > > How much time do you currently devote to Debian? That's hard to say. It varies. Part of being a self-employed consultant is that you get to choose your own hours (to some extent, of course). There are weeks, that I don't do much for work and just do Debian work instead, while there are also weeks that the reverse is true. > How will that amount of time change for the DPL term? How will you > balance your DPL time and time for other Debian activities. I suspect I will have to spend some more time doing Debian work, some less time watching movies (which I enjoy quite a lot), and /maybe/ have some less billable hours, too. I don't think my business partner will care much about that--he holds a SAS "gold" card (about the highest you can get in their milage saving plan), virtue of him flying around the world for his FreeBSD activities, so he better not :-) -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Question for all candidates: Care of Core infrastructure
On Mon, Mar 15, 2010 at 03:45:46PM -0400, Joey Hess wrote: > Marc Haber wrote: > > - The concept of "all services are immediately started after > > configuration" and "deleting all stop/start links will cause the > > package's defaults to be re-established on the next package update" > > is meeting a lot of resistance in the user base lately. Many people > > use this as explanation why Debian is totally out of the question in > > a professional environment for them. > > Is there some reason that these professional environments cannot deploy > a 2 line policy-rc.d? Perhaps someone should make a no-auto-start-daemon > package that contains it? Maybe we failed to provide such a "two-liner", which in fact is, unfortunately, much more complicated than one might think naively. Additionally, example code for policy-rc.d is (almost?) nonexistent. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- 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/20100315225452.gc32...@torres.zugschlus.de
Re: Question to all Candidates: Project Funds and donations
On Sat, Mar 13, 2010 at 12:02:59AM +0100, Martin Zobel-Helas wrote: > Hi, > > this question goes to all candidates: > > 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? I'd prefer not to commit to a specific list, since there'll always be something I'll miss, but good examples include things like "holding meetings", or "buying hardware that we need but that we don't get donated". I don't think we should buy all our hardware (we have many people who are happy to donate a piece of equipment, much more so than money), and I don't think having money on the bank will harm the project in any way. > b) How would you think is a valid way to thank (hardware) contributors? That very much depends on the contributors, and on the motives for their contributions. We should probably start off by saying "Thank you for your contribution. Now is there something we can do in return?" E.g., if hardware or bandwidth donators want us to publically state their name somewhere, we can do that. If there are people who've contributed massive amounts of, er, "stuff", for years, we can probably do something more. > b) What qualifies a contributor to become a "Debian Partner"? What >qualifies a "Debian Partner"? I don't think we have a formal list of "Debian Partners" (but I could be wrong). I'm also not convinced we need one. If we do have such a list that I'm not aware of, it might be a good idea to see if it's working well. I don't think I'll be working much in this area, however. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Question for all candidates: squeeze freeze [ Was: Release process ]
[ Please: can people that follow-up with different questions change the subject accordingly? I believe it would make easier to read the question archive afterwords. ] On Mon, Mar 15, 2010 at 08:09:19AM +0100, Lucas Nussbaum wrote: > 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? (I don't read minds and I'll just report the impression I got of the event as a DD which has assisted to the talk which created "the case" and which, quite normally, thought about it later on.) I think that the event has been a terribly unfortunate coincidence of bad wording by the release manager and of good will on the side of the press team to anticipate how "the media" would have reported the news. I think Luk meant to propose time-based freeze to the project, but got eventually caught in some frenzy of writing it down properly for the media. A honest, yet unfortunate, mistake. Again, this is just my personal feeling, and I have never asked any of the directly involved people about more details. > - 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? IIRC in the talk the release team discussed how they were approached by Ubuntu people about the possibility of doing a coordinated Squeeze/LTS freeze, to ensure that some core sets of packages were in sync. That would have been given the benefit of coordinating stuff like security fixes, important bug fixes targeted at point release, etc. Back then, it seemed that the only way to have such a guarantee were to freeze at the same time, and "therefore" in December. In general, I'm fine with the idea of coordinating specific releases together with derivative distributions, when both distros will benefit from the coordination. (On a smaller scale, it has already occurred in the OCaml team to coordinate the "stability" of all our source packages with Ubuntu freezes.) What I don't like is the above "therefore". Coordination has to go in both ways, if we want to sync *among* Debian and Ubuntu, we should sit together around a table to decide *when* we freeze; it is not that, since Ubuntu releases every 6 months, we should adapt our release cycle accordingly. If we *can* do that, fine, we will balance pro/cons and decide accordingly. In fact, if we manage to ignore for a bit the unfortunate communication incident, the release team had later on contacted the teams of core set of packages in Debian and, on the basis of their feedback, decided not to freeze in December. Having only the second part without the first would have obviously been better, but we are humans and sh*t happens. > - So, we are now in March. What is your opinion with the release process > so far? When do you see the release happening? As a simple DD, I would be happy to freeze by the end of March / early April and, a bit naively maybe, I would be satisfied about the release process thus far if that will happen. I don't have any direct experience in the release team though, so I'll fully trust the team decision if they will eventually decide to postpone the freeze: they probably see complications that I can't see (such as the actual burden that will be induced by the management of unblock requests). All the above opinions on the release process are expressed as a simple DD. If I get elected DPL, and since I agree that similar questions will be most likely posed in interviews & co, I'll coordinate with the release team a set of answers that best represent their views. Cheers. -- 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
Platform
Before I start answering mails and get to the campaigning bit, I should apologise for not writing my platform before the candidacy submission deadline. I agree (in hindsight) with the general feeling here that platforms should be available by the time campaigning starts. As I stated in my candidacy submission, I had an /extremely/ busy weekend; I said "a concert", but there were actually three performances (two on saturday, one on sunday), and I had volunteered to videotape the concert (using dvswitch), which basically meant I had no time left for anything but 'sleep, set things up, and sing'. I just realized that I haven't had a decent meal for the whole weekend. Not that this should matter much to anyone, but like I said, I hope nobody will hold this against me. I just finished writing my platform, and the secretary should be ready to publish them soon, I hope, unless he's still waiting on anyone else. Anyway. Let's get to the campaining! -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- 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/20100315223721.ga10...@celtic.nixsys.be
Re: Question to all Candidates: Project Funds and donations
Hi, On Sun Mar 14, 2010 at 22:10:30 +0100, Stefano Zacchiroli wrote: > - it is not easy enough accessible to DDs (I know, it is enough to > become a SPI member and subscribe to the list, but I still believe it > should be _easier_, e.g. a directory somewhere with archived .txt > files accessible to all DDs) SPI's Treasurer, Michael Schultheiss, (and by the way Debian Developer) does a really good job by sending out monthly Treasurer's Reports which are in every monthly meeting minutes linked from http://www.spi-inc.org/corporate/meeting-minutes Greetings Martin -- Martin Zobel-Helas | Debian System Administrator Debian & GNU/Linux Developer | Debian Listmaster Public key http://zobel.ftbfs.de/5d64f870.asc - KeyID: 5D64 F870 GPG Fingerprint: 5DB3 1301 375A A50F 07E7 302F 493E FB8E 5D64 F870 -- 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/20100315221302.gk23...@ftbfs.de
Re: Question for all candidates: Release process
On Sun, Mar 14, 2010 at 02:44:15PM -0700, Russ Allbery wrote: > Releasing is regularly the hardest thing that Debian does, not just > technically but also socially. To some extent, I believe it is normal. Releases are our main "products", they define our purpose. The people which are putting their names in driving the release process, i.e. the members of the release team, are very tightly bound to the release process. The closer we get to a release, the closer they might feel pressure, which sometimes has unfortunate consequences. My impression is that most impromptu resignations in Debian happen as a consequence of some form of burn-out, which are unfortunately not uncommon in volunteer FOSS projects. I don't believe the release team constitutes an exception to this unfortunate rule. A general cure to this is to avoid people taking over their shoulders more responsibility than they can handle. I was very positively impressed when Steve McIntyre's team review of two years ago found out people involved in an incredibly high number of Debian teams and actually incouraged those people to step back from some of them. We should encourage DDs to periodically review their involvements and focus their energies on a few specific areas. Being a member of the release team, or even the release manager is, again, no special case. As it is hard to actively state "I step back", we should also more frequently do (self-)appointments with an attached "expiry date", when the date expires the involved people can "snooze" it actively or just let others know that it is time for them to move on to Debian activities which are more fun for them. > Do you have any thoughts about how to resolve release issues with less > hurt and negative impact to the project all around? On one hand, I believe that the pressure on, and even some personal conflicts with, the release team could have been much lower in the past (generally, not necessarily only in this last release process) with a bit more communication with project. As a DPL, I would generally prod the release team for periodic status reports (at least monthly) which are much needed, considering the peculiar role of the release process in Debian. If prodding is not enough, the DPL can also take care of the communication him/herself. On the other hand, I think the release team has felt in the past more than a bit of frustration, due to the apparent disinterest of DDs in getting a release done. I particularly remember during DebConf8 (Lenny release cycle) a deserted BSP which was largely perceived as lack of interest in getting the RC bugs count down. That is just an example and maybe not even the most appropriate one [1], but the problem exists: beside maintainers that don't care about fixing RC bugs in their packages, not so many people care about helping in releasing Debian, by working on packages other than theirs. That can easily make the release team feel "alone against the release", which is surely not a productive context to work in. Ultimately, I believe this is a cultural problem that will take us quite some time to fix. I'm aware of various initiatives in the right direction: - use the NM process to coach newbies about the importance of fixing packages other than theirs (we already request to provide RC bug patches during T&S). I personally had very good responses on this from a couple of NMs which started patching and/or NMU-ing RC-buggy packages with (proper) patches just after becoming DDs - more generally, diminish strong package ownership by communicating that contributions like NMUs are good, as long as they are done following the rules (initiatives like RCBW and its predecessors attracted quite a lot of "minions", for instance) The ideal bottom line of this is that, if the DD body starts feeling more part of the release process (rather than only thinking at their own pet packages), then DDs will more and more stand on the side of the release team, rather than against it. Cheers. [1] one can argue that a DebConf should better be used in other ways, etc -- 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: Question for all candidates: Care of Core infrastructure
Marc Haber wrote: > - dpkg still uses normal console prompting for dpkg-conffile > handling, while debconf has been mandatory for regular packages for > years now. Dpkg has more active development now than it has for much of the past fifteen years. And they've even talked some about implementing debconf conffile prompting and fixing other much worse dpkg/debconf integration points. That's fairly minor compared to developing saner source package formats, really. One could complain that debconf itself is not being as well maintained as it might be. One of its two maintainers avoided having anything to do with Debian for a full year recently. Especially the transition to using cdebconf has been stalled far too long, on some bugs that are documented and should be a straightforward matter of coding to fix. > - The concept of "all services are immediately started after > configuration" and "deleting all stop/start links will cause the > package's defaults to be re-established on the next package update" > is meeting a lot of resistance in the user base lately. Many people > use this as explanation why Debian is totally out of the question in > a professional environment for them. Is there some reason that these professional environments cannot deploy a 2 line policy-rc.d? Perhaps someone should make a no-auto-start-daemon package that contains it? I have seen a lot of users run into the update-rc.d link issue, but never seen any perceive it as anything more than a minor gotcha that you learn the workaround for. -- see shy jo signature.asc Description: Digital signature
Re: Question for all candidates: Care of Core infrastructure
On Mon, Mar 15, 2010 at 11:30:39AM +0100, Marc Haber wrote: > 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? I'm a bit more "pessimistic" than you when looking at the past: this is a problem which has more or less always plagued Debian, at least while I've been around. A lot of QA activities are for instance concerned with getting rid of "yet another package with a popcon of 5". If the lack of manpower in the core infrastructure looks more acute these days, it is probably because the overall amount of Debian manpower is lowering (which is worrisome per se). I agree that there is no silver bullet in DPL hands to fix that, and I surely agree that in most cases the problem do not lay in teams not accepting members [1]. Something I'd like to try if elected DPL is to keep a list of teams "in need of help" [2]. Then, periodically and at worst in my monthly "bits from ..." posts, I intend to have a section which kind of makes a "focus on" the specific team which is looking for new people. It is probably nothing and won't change much, but it is a worthwhile attempt. I also consider a responsibility of the DPL to prod specific people to join core teams which are understaffed, as I believe has pretty much always happened with past DPLs, but that can be no more than invitations, in agreement with the involved team. (And no, that's no excuse to lack transparent join rules for the team, it is just a way to have "team staffing" going in both directions: passive and active.) Cheers. [1] ... and when I see young, motivated, and very active DDs entering core teams as it happened in the past years in teams like release and ftp masters, I'm *very* delighted. [2] yes, that list probably equates the overall list of Debian teams, but managing priorities is something a DPL is expected to do, right? -- 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
Platforms.
Hi Wouter, Hi Charles, I'm still waiting for your platforms. I would have liked to publish them last Friday, and already postponed it to today. If I don't receive them by tomorrow around this hour I will start to publish the others that I did receive. I'm also going to postpone the rebuttal and would like to publish that at the 22nd. Kurt Roeckx Debian Project Secretary signature.asc Description: Digital signature
Re: Question to all Candidate: In ten years...
On Mon, Mar 15, 2010 at 12:47:07PM +0100, Alexander Reichle-Schmehl wrote: > > In fact, we are already quite peculiar in both above two points, but we > > are often not seen as such because we are not particularly good at > > communicating them. I'd like Debian to fix that way earlier than 10 > > years from now :-) > How? I believe those values should be some of the first things we tell about us on our website. Something along the lines of "debian is a distribution ..., which is free the bottom up (both in its software and in its infrastructure) and which is completely do-ocratic and democratic". That is not exactly how I'd write it on a website, nor it is a specific call of the DPL. However, *proposing* something like this to the WWW team is something I intend to do, if elected. Cheers. -- 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: Will you withdraw delegations of DD not behaving correctly?
On Mon, Mar 15, 2010 at 1:57 PM, Stefano Zacchiroli wrote: > On Mon, Mar 15, 2010 at 09:10:23AM -0300, Margarita Manterola wrote: >> A new Code of Conduct has already been drafted, but it has never been >> put into practice. > > What are you referring to here when you write "Code of Conduct"? Do you > mean the Debian Community Guidelines (as I guess), or rather > http://www.debian.org/MailingLists/#codeofconduct ? Yes, the Community Guidelines. As I've always understood that the idea of these Guidelines is to eventually replace or enhance the CoC, I consider them a draft for a new CoC. I think that they should be validated by a vote, so that we can know if the community as a whole agrees with them or not. However, I don't know why Enrico hasn't submitted such a vote. -- 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/e8bbf0361003151009r517868bdkc2d74cfefd573...@mail.gmail.com
Re: Will you withdraw delegations of DD not behaving correctly?
On Mon, Mar 15, 2010 at 09:10:23AM -0300, Margarita Manterola wrote: > A new Code of Conduct has already been drafted, but it has never been > put into practice. What are you referring to here when you write "Code of Conduct"? Do you mean the Debian Community Guidelines (as I guess), or rather http://www.debian.org/MailingLists/#codeofconduct ? Just to understand if I'm missing something :-) Thanks, Cheers. -- 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: Will you withdraw delegations of DD not behaving correctly?
On Mon, Mar 15, 2010 at 08:13:23AM +0100, Raphael Hertzog wrote: > Most of you have answered that it's not possible to regulate the heated > discussions but it's possible to set a good example. If only the leader > behaves properly, it will still be difficult to make the climate change. > But if all the delegates behave properly, and if delegates that do not > behave properly are withdrawn due to this, we might get better results. FWIW, I've also stated that: (1) others than the DPL should equally set an example and, more importantly, exercise peer pressure on who is "misbehaving" and (2) that we should start forming the next generation of DDs. (This is not a criticism on your representation of answers, just a clarification on my position.) > 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? I agree on your point that: having the DPL setting an example is one thing while having all the DPL + core teams doing that is another (much better) thing. That means that the DPL, for the benefit of the whole project, should do his/her best to have core teams communicating "properly". I will surely mail, privately first and then publicly next, a delegate which is "behaving badly" (your wording) about that. Frankly speaking however, I don't see much the reality of your example, or maybe I'm just missing what you've in mind when you write "behaving badly". Of course I'd consider unacceptable for a delegate to repeatedly, e.g., insult someone on list. Such a behavior would warrant early warning and eventually even delegation withdrawal. But I don't remember any such extreme example in the recent past. If you've specific examples, please reference them and I'll be happy to tell you what I'd done. In fact, the most frequent remark on the communication of delegates is about the lack of it. If elected DPL, I would surely encourage delegates to communicate periodically about what they're doing. Nevertheless, we should remember that communicating *is* an additional burden and while the DPL can decide for him/herself how to balance his own efforts (I've already discussed in another thread my intended personal balance), the DPL cannot *force* such decision on delegates. I'm convinced that in most cases the DPL has alternative levers though: for instance the DPL can communicate _in place_ of the delegates (giving proper credit), can pose a kind of _periodic communication requirement_ when establishing new delegations, can appoint _new people_ as co-delegates choosing people that do like communicating. Let's remember that there are people that like to communicate, even among geeks, it is just a matter of associating them with complementary kind of people. > 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? I don't like the idea of using Code of Conducts (CoCs) to retaliate a posteriori saying « see, you've just violated CoC §1.2.3.4 ». It can't work that way in our Debian world, where even if we can establish trials, those trials will simply get the fun out of all involved people (and often a lot more). I rather believe that CoCs, and the signatures apposed thereon, exist to have people read them and, in the long run, to create a specific culture within a project (that's why I would like the idea of having some document along these lines read and possibly signed during the NM process). To that end, delegates are not special DDs and should not have specific CoC to sign. Cheers. -- 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: Question for all candidates: Release process
Hi Frans, Let me first start by stating that I'm sadly concerned about the tone of your mail. Nobody claims that the release process has been done perfectly, there have been mistakes, but we are all human and we can all make mistakes. It's alright to point those mistakes out so that people can correct them, but I find your mail disturbing, because it feels more like attacking the past Release Managers than trying to improve the overall project quality. With that in mind, I'll answer only a few of the issues you raise, those that I feel are relevant to the upcoming election. On Mon, Mar 15, 2010 at 12:30 PM, Frans Pop wrote: > The Release Team should IMO keep in mind that it's not *they* who make a > release, but the whole project together. And the best way to get respect > for their work is for them to respect the vastly bigger amount of work > done by all other DDs collectively. I think that the whole project should keep that in mind, not just the Release Team, and I feel there are many people who don't care enough about releases and thus do not help out. I agree that communicating more often could help, but it would also be necessary to agree on some common goals for the project, so that we really are working all together as a community instead of just doing some solo work. That's one of the things I plan to do as DPL: establish (by talking with the affected teams) some common goals to work on, and communicate them project wide so that we are all working together towards that. > Ideally the Release Manager should > spend more time on communicating with the rest of the project than on > handling transitions. I agree with this (and many of the removed-due-to-being-aggressive quotes). However, the lack of man power means that the Release Managers end up in charge of transitions and lack the time to do the real communication and coordination. The role of the DPL is to help developers do their work as good as possible. In this case, the only thing that can be done is try to inspire more people to help out with the release team, but this is not an easy task, since working on transitions requires extra knowledge that many DDs don't have, and the release team members don't necessarily have the time to train them. We currently and very sadly don't have a Release Manager. Please let me suggest that, when a Release Manager is appointed, you should direct your suggestions about management to them, focusing on what could be done better, without the need to attack whatever was done wrong in the past. -- 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/e8bbf0361003150916o58d9f400x88b4dbe793a7a...@mail.gmail.com
Re: Question for all candidates: Release process
Margarita Manterola wrote: > I think that most of the frustration comes from the fact that the > release team is lacking manpower. The job of the release team is very > stressful and very rarely do the RM and RA feel that their work is > appreciated. I disagree. I think the main problem is that there are two main sides to what the Release Team does and that the cause of the frustration on the side of the rest of the project is that one of those is sides has been neglected. And that frustration in the rest of the project creates the negative feedback and criticism which in turn creates the stress in the RT. The two sides I'm talking about are: - the technical work around preparing a release This includes managing transitions, migrations; doing removals; maintaining tools; etc. This seems to be what the RT has been focussing on after Sarge. This is also where most manpower currently goes. And it's very necessary and important. And in general I think it's done quite well (except when someone decides - without any prior announcement or opportunity for review or comment - to do a mass removal of packages from testing because they have a random RC bug open even though the importance of the package massively outweighs the practical impact of the bug). - the actual *management* of the release process This involves planning and coordinating the work that needs to be done by "regular" DDs; ensuring that not only the archive is in a releasable state, but that also the website and documentation (including translations) have been updated; stimulating BSPs; preparing release announcements (and giving people who's work your announcing time to review and comment what you've written for them); informing everybody involved of the status and progress of a release. And also tracking the status of architectures and *discussing* with the project what to do when an arch has problems (instead of just deciding on things in isolation); keeping track of release goals and stimulating work on them so that they are actually implemented, The quality of a Debian release is determined by much more than just the RC bug count. And it all needs to be managed, or at least coordinated. And *everything* needs to be ready on the day, not just one aspect. During the Sarge release these two sides were in balance. After that, for Sarge stable releases and the Lenny release, the second side was horrible. And several people contributing a lot of work in strongly release-related areas have been driven away by that. After Lenny things have improved in some areas (communication about ports has been quite good for example and so has the management of the last couple of stable point releases), but for Squeeze we've only seen a very few rather general status mails, but no coordination at all. The Release Team should IMO keep in mind that it's not *they* who make a release, but the whole project together. And the best way to get respect for their work is for them to respect the vastly bigger amount of work done by all other DDs collectively. The fact that they control the switches does not mean that they can unilaterally make any decision regarding the work of others. There is no problem with the RT making the *final* decision about release related issues, but they simply cannot make most decisions without checking with the rest of the project. If only simply because in most cases they won't have all relevant information. And checking with the rest of the project is *not* asking a few buddies on a selected channel on IRC. It's doing proper announcement and RFC/RFRs on the mailing lists intended for that purpose. And finally, the best way to get help is to be open about what you're doing. If you hide yourself away and don't communicate with the project you don't get help. I think the very noticeable change in the FTP team is proof of that. IMO for a lot of the above the primary responsability lies with the person with the title/role of Release Manager. Ideally the Release Manager should spend more time on communicating with the rest of the project than on handling transitions. The challenge for an RM when the team can't handle the workload is not to do it all himself, but to continue communicating and get help. Cheers, FJP -- 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/201003151630.25818.elen...@planet.nl
Re: Question for all candidates: Care of Core infrastructure
On Mon, Mar 15, 2010 at 7:30 AM, Marc Haber wrote: > 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? As you say, this is quite not in the power of the DPL to solve. The only way that the problems listed by you and by the other messages in this thread could be solved is by inspiring people to work on those issues. How? That's a very tricky question, since people are inspired in several different ways. However, it's quite common for people to approach the project (be it through a mailing list, IRC or maybe personally asking a DD), saying that they want to "Help Debian"... But we don't usually list those core tasks as ways of helping Debian, because they are seen as too important for newbies to help with. I'm thinking that we could try to have a more fancy "Get involved in helping Debian" page, where all teams that welcome help could post their tasks and try to attract new contributors. Maybe even have a parallell page that is only for DDs (since, for example, the release team and ftp team require DDness, because the needed machine access), and invite DDs to contribute more to Debian through it. Having the requests for help more visible and easily findable by more people would hopefully lead to more people helping out. Or not, but I think it's worth trying. Apart from that, I cannot think of a way to fix the core teams lack of manpower. It's not -like it used to be in some cases- that the teams are not accepting new members, so we only need to reach the people that want to join. -- 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/e8bbf0361003150827k7301159dl348b7e436c1d7...@mail.gmail.com
Re: Question for all candidates: Release process
On Mon, Mar 15, 2010 at 4:09 AM, Lucas Nussbaum wrote: > 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 went wrong: a decision was taken without consulting the affected teams. This is a situation that has happened over and over again in Debian. The Debian community does not take it well when they are informed of a decision already taken without having a say on it. We should learn from this to never make this mistake again: always keep involved participants in the loop and consult with other people before announcing something as a taken decision. What went right: after the many messages stating that the December freeze was NOT a good idea, specially after Mark Shuttleworth clarified what he meant by "freeze" (stating which versions to include in the release), the Release Team sent a mail saying that freezing in December was not a good idea and that the freeze would most probably happen on early 2010. > - 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? I think it's generally a good idea, *BUT* I think we should freeze about the time when Ubuntu releases the LTS, *NOT* 4 or 5 months before. Because, as we all know, Ubuntu doesn't really freeze until really close to the release. So, freezing before that is the same as not coordinating at all. This would mean that Ubuntu would release the LTS in April and Debian would release maybe in July or August. I'm perfectly ok with that. I also think that releasing roughly every two years, with a kernel/X/etc upgrade in the middle (like was done with etchnhalf), is good. I value stability far more than "bleeding edge", and I know that releasing more often than that is going to have quite an impact in stability. Where I work, most users (about 150) are still using Etch, because they are used to it and have no real need of anything newer. All in all, this is my opinion as just a DD. The release process is the work of the Release Team, and it's their call in the end. However, to avoid the turmoil caused last year after the DebConf keynote / press release, the RT should always keep involved teams in the loop when setting a release (or freeze) date. > - So, we are now in March. What is your opinion with the release process > so far? When do you see the release happening? I'm very saddened by Luk's resignation from yesterday, I think it's mainly the result of having to do too much work by too few people. This leads to stress and frustration, and those tend to lead to resignations. Now we have to give the team some time to re-arrange themselves and find a way to continue. I won't make any predictions, since they'd make very little sense in the current context. I do plan to help the Release Team releasing squeeze, in whatever my capacity, and I'm hoping that it'll happen this year, so that the whole LTS syncing thing can happen. However, if in order to have a stable, robust and clean release we ended up releasing in 2011, I'd still consider it a good trade off, and I'd still back up the Release Team. -- 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/e8bbf0361003150814w52c2ee60h9ab8050311128...@mail.gmail.com
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 for all candidates: Release process
On Sun, Mar 14, 2010 at 6:44 PM, Russ Allbery wrote: > 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. There's usually always at > least some frustration, anger, and upsetness, and there seems to usually > be at least one resignation over the course of a release, often in a way > that hurts other activities in Debian for a time. I think that most of the frustration comes from the fact that the release team is lacking manpower. The job of the release team is very stressful and very rarely do the RM and RA feel that their work is appreciated. > Do you have any ideas how, as DPL, you would (or even could) address this? I've been thinking about this, due to the recent events, and I'm not sure I have a solution. As I've already commented, I'd like to set up some projects that encourage more external (and internal as well) contributors both to report and fix more bugs. However, there's much more to the release work than fixing RC bugs: managing transitions is a LOT of work, that requires extra knowledge, and only DDs can do it. We know from past experiences that throwing money at the problem would only bring more trouble, so that's out of the picture. So, the only way I see to help is documenting the work needed and asking for help. Maybe if more DDs knew the work needed to get their own packages into testing, they would be able to help there, and reduce the pressure on the Release Team. > I'm personally the most concerned with the social issues. A delayed > release can be frustrating but doesn't have that much negative impact, but > volunteers with enough knowledge of Debian to be able to serve as release > managers or helpers are rare. And usually the arguments not only hurt > their contributions to Debian but usually hurt the contributions to Debian > of the people on the other side of the argument as well, who are often > also valuable and difficult-to-replace volunteers. I agree with all of this, and I'm very much concerned about this myself. However, I don't see an easy way to fix this. My ideas are on how to make it easier to help out, but people won't necessary want to help, and I can't think of a way to magically make people want to help. -- 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/e8bbf0361003150642h6d3f431ejb3b1bd852f5b4...@mail.gmail.com
Re: Question for all candidates: Care of Core infrastructure
Le lundi 15 mars 2010 à 12:54 +0100, Marc Haber a écrit : > Agreed. Any more additions by others? Core packages: glibc, kernel, X.org, Mozilla, KDE, GNOME… These are the packages everything else is built upon, yet people are more interested in adding yet another implementation of existing functionality. Cheers, -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same `- as a signed contact.” -- Jörg Schilling -- 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/1268659695.30798.12.ca...@meh
Re: Question for all candidates: Care of Core infrastructure
Hi! Marc Haber schrieb: >> - Debian Installer development >> - Porting: several ports are struggling >> - Documentation maintenance: >> - website >> - Release Notes >> - various other guides > Agreed. Any more additions by others? ftp-team and more or less everything PR related. Best regards, Alexander signature.asc Description: OpenPGP digital signature
Re: Will you withdraw delegations of DD not behaving correctly?
On Mon, Mar 15, 2010 at 4:13 AM, Raphael Hertzog wrote: > Most of you have answered that it's not possible to regulate the heated > discussions but it's possible to set a good example. If only the leader > behaves properly, it will still be difficult to make the climate change. > But if all the delegates behave properly, and if delegates that do not > behave properly are withdrawn due to this, we might get better results. > > 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? As you say, I think that it's very important that key Debian people set a good example, not only the DPL but all the delegates, yes. However, I wouldn't dismiss anyone so easily, it would have to be a recurring situation (i.e. more than twice or three times) and of a high level of misbehavior for it to lead to un-delegation, and that would be only when all the other options (like talking privately, mediation, etc) had been unsuccessfully explored. Were such a misbehavior to happen with me as DPL, my first attempt would be to talk privately with the people involved, trying to find a way that the situation can be solved, maybe even with a public apology if that's needed. I think it's better for everybody to try to grow into better selves, than just dismiss whoever is not behaving properly. > 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? A new Code of Conduct has already been drafted, but it has never been put into practice. I guess that we should vote upon it, to see if the developer body wants to have it. If the vote is successful, the code of conduct can be enforced for everybody and not just for delegates. In any case, I agree that the people in the core roles should be the ones that show the best behavior. -- 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/e8bbf0361003150510s3dccc49fhc68c365ab93ea...@mail.gmail.com
Re: Question for all candidates: Care of Core infrastructure
Hi, On Mon, Mar 15, 2010 at 12:52:44PM +0100, Frans Pop wrote: > IMO it's worth adding to that: > - Debian Installer development > - Porting: several ports are struggling > - Documentation maintenance: > - website > - Release Notes > - various other guides Agreed. Any more additions by others? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- 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/20100315115422.gc15...@torres.zugschlus.de
Re: Question for all candidates: Care of Core infrastructure
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 -- 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/201003151252.45199.elen...@planet.nl
Re: Question to all Candidate: In ten years...
Hi! Stefano Zacchiroli schrieb: > In fact, we are already quite peculiar in both above two points, but we > are often not seen as such because we are not particularly good at > communicating them. I'd like Debian to fix that way earlier than 10 > years from now :-) How? Best regards, Alexander signature.asc Description: OpenPGP digital signature
Question for all candidates: Care of Core infrastructure
This is for all candidates. 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. I am not saying that noone seems to care, but I see a lot of annoying issues not being addressed. An totally incomplete list: - dpkg still uses normal console prompting for dpkg-conffile handling, while debconf has been mandatory for regular packages for years now. - it is still not possible to control package A's dpkg-conffiles from package B, the canonical suggesting being cfengine and/or puppet - aptitude is unable to display its conflict solutions for months now - The concept of "all services are immediately started after configuration" and "deleting all stop/start links will cause the package's defaults to be re-established on the next package update" is meeting a lot of resistance in the user base lately. Many people use this as explanation why Debian is totally out of the question in a professional environment for them. - The release team has been crying for help multiple times with nobody being willing to step up and help. 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? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- 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/20100315103039.ga15...@torres.zugschlus.de
Will you withdraw delegations of DD not behaving correctly?
Hello, another question to all candidates (this question is inspired by a recent event). Most of you have answered that it's not possible to regulate the heated discussions but it's possible to set a good example. If only the leader behaves properly, it will still be difficult to make the climate change. But if all the delegates behave properly, and if delegates that do not behave properly are withdrawn due to this, we might get better results. 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? Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ signature.asc Description: Digital signature
Re: Question for all candidates: Release process
On 14/03/10 at 14:44 -0700, Russ Allbery wrote: > This is for all candidates. > > 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. There's usually always at > least some frustration, anger, and upsetness, and there seems to usually > be at least one resignation over the course of a release, often in a way > that hurts other activities in Debian for a time. > > Do you have any ideas how, as DPL, you would (or even could) address this? > I'm personally the most concerned with the social issues. A delayed > release can be frustrating but doesn't have that much negative impact, but > volunteers with enough knowledge of Debian to be able to serve as release > managers or helpers are rare. And usually the arguments not only hurt > their contributions to Debian but usually hurt the contributions to Debian > of the people on the other side of the argument as well, who are often > also valuable and difficult-to-replace volunteers. > > Do you have any thoughts about how to resolve release issues with less > hurt and negative impact to the project all around? Three more release-related questions. 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? (I'm fully aware that the DPL is not in a position to take many actions regarding the release. However, similar questions are likely to be asked during post-election interviews, so we would better know how you will answer ;) -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- 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/20100315070919.ga26...@xanadu.blop.info