Re: Question for DD candidates: The race against NOTA
Hi, On Tue, 16.03.2010 at 22:32:22 -0600, Gunnar Wolf gw...@gwolf.org wrote: As per Constitution 5.2.4, the vote should be repeated, as many times as needed. Lets just assume it was different: The project has voted not to have a leader anymore. What would be different if there was no leader? Where would the project lose more? Would it gain in some aspect? I am not a candidate, but I can immediately see that the press would take the voice of random DDs as the voice of the Debian project in cases when it wants a statement. As we were not unanimous on many issues in the past, just imagine what if one of the people who are no longer around would have been able to make official statements on behalf of Debian. I bet that this could become quite interesting. ;} Kind regards, --Toni++ -- 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/20100317102757.14648.qm...@oak.oeko.net
Re: Question for all candidates: Release process
* Charles Plessy ple...@debian.org [100317 01:52]: I propose that we reshape the sections and priorities of our archive, so that it is easy to remove from Testing any RC bug that is not in a core pakcage, and is old and not tagged RFH. How is that different from the current procedure? In parallel, I propose that the definition of what the ‘core’ is can vary between architectures. And do you think that will make it easier or harder to do a release? The goal is not only to reduce the workload of the release team and the porters. It is also to give some meaning to the presence of a package in a stable release. These packages must be there because there is agreement that enough users are insterested in it, and are comfortable with the idea to keep it at the same version for a long time. So you think we currently put things in which we do not want to keep the whole time? For many peripheral leafs and branches of our dependancy tree, let's innovate and distribute them through other channels, like official backports and even the new snapshot system that is being set up. Welcome to the first circle of rpm hell... Bernhard R. Link -- 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/20100317101519.ga31...@pcpool00.mathematik.uni-freiburg.de
Re: Question for all candidates: Release process
On Tue, Mar 16, 2010 at 09:56:56PM -0600, Gunnar Wolf wrote: Wouter Verhelst dijo [Tue, Mar 16, 2010 at 12:57:13AM +0100]: 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. Hmm, you got me thinking here on why this happened, as I share your impression. Maybe it was because the project as a whole put more care into the release process after the massive pain it was to release Sarge, a three-year-long pain we didn't want to suffer again? For Lenny we lost some of that push, although the release process was still mostly swift, with a minor slip regarding what we expected. This is quite possibly correct. As for the reasons why we are not freezing yet... I think it is somewhat a lack of commitment to what the Release Team says, as (too) many people felt betrayed with the way the freeze-related announcements were made (a topic that has already been analized here). I don't sense it that way. There was initially a bit of disappointment among many people, indeed, but with the change of plans that was made fairly quickly, I think the trust was restored. So, going back to the questioning of the candidates: Do you agree with this very simplistic analysis? If so, how would you push to get the drive and the confidence back? To get the drive back is something that the release team needs to do. I can work with them on that, if necessary, but I can't do it for 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 10:56:58PM -0600, Gunnar Wolf wrote: Wouter Verhelst dijo [Tue, Mar 16, 2010 at 01:45:33AM +0100]: 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. Umm, yes, but during the seven years I have been part of this project, we shifted from a collections of mostly solo-maintained to a good number of team-maintained packages. And we have opened the DM scheme (imperfect but still much better than not having it IMO), which brings in important numbers of new contributors. Certainly. But there's still a difference between a Debian Developer and a DM. Nobody can do a sponsored upload, except a DD. Nobody can do an NMU, except a DD. Nobody can maintain a buildd host, except a DD. This implies that there are some fairly important jobs that can only be done by DDs. And since reaching Debian Developer status is usually a sign of gaining a certain level of experience with Debian and Free Software in general, this means that most of the core contributors to Debian are those same DDs. So while I agree that the situation isn't as dramatic as a simple look at the number of DDs would seem to suggest, I think it could easily become that if we don't act. [...] -- 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 DD candidates: The race against NOTA
On Tue, Mar 16, 2010 at 10:32:22PM -0600, Gunnar Wolf wrote: So, today is April 15, and our Secretary prepares for a very difficult announcement: There is a majority of votes for NOTA. Or we didn't reach quorum. Or whatever you fancy - But the result is, none of the four candidates won the election. As per Constitution 5.2.4, the vote should be repeated, as many times as needed. Lets just assume it was different: The project has voted not to have a leader anymore. What would be different if there was no leader? Where would the project lose more? Would it gain in some aspect? The DPL has always been a job of coordination: when important decisions were made that involved loads of stuff, often the DPL would be included in that decision, even if he didn't have any prior knowledge of the subject. This is valuable, because it means the DPL knows at least a bit about loads of the goings-on in the project, and can have two (groups of) people talk to eachother if (s)he thinks that would help them both out and they didn't know about eachother. We would lose such coordination, which I think is quite important. Also, we would lose a single face to the project, as Toni already mentioned. -- 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 Tue, Mar 16, 2010 at 09:56:56PM -0600, Gunnar Wolf wrote:
Hmm, you got me thinking here on why this happened, as I share your
impression. Maybe it was because the project as a whole put more care
into the release process after the massive pain it was to release
Sarge, a three-year-long pain we didn't want to suffer again? For
Lenny we lost some of that push, although the release process was
still mostly swift, with a minor slip regarding what we expected.
I do think this kind of analysis is a bit too simplistic to explain what
has happened. Our release cycles are long enough to encompass *a lot* of
factors that can impact on how good a release cycle is perceived to be
by DDs. For sure all of us experienced the pain of getting Sarge out,
but I don't believe that, as a consequence, our collective conscience
has risen up and got a better Etch release cycle.
FWIW, I haven't personally felt the Lenny release cycle to be worse than
the Etch one, both felt quite slick to my DD eyes.
As for the reasons why we are not freezing yet... I think it is
somewhat a lack of commitment to what the Release Team says, as (too)
many people felt betrayed with the way the freeze-related
announcements were made (a topic that has already been analized here).
I don't think the residual effects of the past-DebConf-flames had much
(cascade) effect on why we are not freezing yet. All in all the usual
reasons for not freezing are a too high RC bug count [1] and some
important work still to be completed (e.g. big transitions). If we are
not freezing yet, it is most likely do to those classical reasons, no
need to piggyback others, IMO.
So, going back to the questioning of the candidates: Do you agree with
this very simplistic analysis? If so, how would you push to get the
drive and the confidence back?
Essentially, I believe I disagree with the analysis :-)
Ultimately, driving the release process is the specific role of the
release team, on which the DPL should not intervene directly. The help
that the DPL should contribute to the release team is of a different
nature: helping in staffing the team if/when needed, ensure that the
release team communicates periodically about the release status (by
prodding the team and/or helping them to send out status bits),
motivating developers to feel part of the release process. The above
items are not specific of any release cycle, it is just what I think it
should be a sane relationship between the DPL, the release team, and the
DD body.
Cheers.
[1] I've discussed in another thread how I think we need a cultural
shift on that, making it more distribute within the project. Of
course this is nothing specific to the current release cycle, but it
gets more and more important as our distro grows
--
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 Wed, Mar 17, 2010 at 12:01:14PM +0100, Wouter Verhelst wrote: Nobody can do a sponsored upload, except a DD. Nobody can do an NMU, except a DD. Nobody can maintain a buildd host, except a DD. It was pointed out to me on IRC that yes, there are sponsored NMUs, and that it therefore is 'strange' to mention those as separate points here. While that is really orthogonal to the point I was trying to get across, namely that there are several important jobs that only DDs can do, I should perhaps clarify what I meant here: that an NMU is something that, while it can be *prepared* by someone else, only a DD can do; and since sponsors are supposed to check packages before they upload (especially if the package is by someone they don't know), it usually means little if any reduction in the work for the DD (who will do the non-maintainer upload), anyway. -- 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 Candidates: Disappearing DPLs?
On Tue, Mar 16, 2010 at 08:30:03AM +0100, Gerfried Fuchs wrote: I have a question to the candidates: History has shown that DPLs more or less disappear not too long after their period or at least reduce their visible efforts immensly. I wonder where you see the reasons for this trend, what your impression is about it and wether you try to follow that trend or what you will try to do to not have this happen to you, too. My guess is that it's a combination of factors. First, if you look at the developer body, I think you'll see that there are very few developers who've been in Debian for more than, say, a decade and are still very active and on the forefront. Being a Debian Developer demands a fair amount of time from people, and it's only normal that one cannot keep up a nearly full-time commitment (in some cases even in parallel to a full-time dayjob) for a whole lifetime. Second, I think you'll agree with me that the chances of someone who's not been part of the project for a very long time (say, only one or two years) to be elected are not the same as those who are active longer, and/or are better known. In other words, people who are DPL are on average already well-known long-time contributors who may run out of time or motivation to work for Debian within a few years. If you combine the two, you'll see why I think that while there does seem to be a correlation between 'is DPL' and 'has a high chance of resigning soon', I do not think there is a causal relationship. While a job that demands a lot of time, like the DPL position, may *speed up* the process of people resigning from the project, I do not think it will *cause* the same. As such, I don't think there's much I can do to prevent it. I know that if there is a day when I feel I cannot motivate myself anymore to work for Debian, I will not stay and stand in the way of people doing work. I love Debian too much to do that. But I don't expect that to happen soon. -- 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 Candidates: Disappearing DPLs?
On Tue, Mar 16, 2010 at 08:58:42AM +0100, Stefano Zacchiroli wrote:
DPLs continue to be volunteers and as such they can be hit by any kind
of time demands from their job, their personal life, etc. Probably, the
fact that they are in a central position, which is expected to
communicate a lot, make their disappearance more evident than those of
other fellow DDs.
That being equal for all volunteers, there are probably additional
causes such as: the burden of the task (I imagine), extra-stress, and
even burn-out. I personally take these latter risks very seriously and
that's part of the reason why, if elected, I will put on all my other
Debian activities for the duration of the term.
Discussing this question on IRC I've realized that, when I wrote the
above, I was answering a slightly different question than the one
actually posed. I was answering to what I plan to do to avoid
disappearing after the _election_ rather than after the end of the term.
It turns out that my intended course of action applies to both,
though. I think that most disappearing ex-DPL do disappear due to some
form of burn-out and/or excessive stress accumulated during the term.
What I plan to do to mitigate both risks would help avoiding that too.
However, I won't be surprised ending up _changing_ some or several of my
Debian activities at the end of the term, if elected. I believe that
most of us need periodic rotations in their (Debian) interests: as
hackers we all love what keeps high our tech excitement and it is normal
for that to have a significant overlap with new interests (for some
value of new). Given that I plan to put on hold my current Debian
activities, I will probably get attracted by different ones when
evaluating which to restart.
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
Q for all candidates: (Old) Architecture Support
Debian has been known through the years for its excellent support for many architectures. In theory, a released arch should be as stable as the common/popular archs. (In practice, it is/was pretty close, which is good enough.) This asset is not something to be proud of because of shallow marketing reasons -- it benefits the whole Free World as many bugs are uncovered, reported, and fixed, quite often by Debian people. It would not be incorrect to say that, having in mind how many packages are available in the archive, and the GNU/Hurd + GNU/kFreeBSD ports, Debian is the most comprehensive testground of the GNU system. There is a disturbing and unpleasant tendency (which probably has its roots in the Dark Times, i.e. the Vancouver Proposal) to drop support for some problematic archs as years go by. That's entirely understandable, but: - m68k was the first kicked out arch. AFAICT, it is essentially dead now and not even a miracle can save it. - alpha will not be released with squeeze; I dare to speculate that it will be in the position of m68k within a release or two. - Debian is the last GNU distro with a sparc port (Gentoo has sparc too, but it's actually sparc64); squeeze+1 will probably drop sparc. (Again speculation/clairvoyance: sparc will follow m68k's footsteps pretty soon too, especially having in mind that there's no or little upstream support.) - hppa was (and always is, it seems) at great risk, although thanks to the Herculean efforts of the porters it is in a good shape (as far as I can judge) now. - mips/mipsel are probably the most hated archs by DDs in the past few months :-), and there's no ironclad way to secure their future too. So, having in mind the obvious conclusions a sensible person could do, namely * Support for old (and not only old) architectures cannot be infinite; and there's a line to draw somewhere when it comes to a release. * There should be an entitiy within the project to decide which arch gets released and which not, which one is blocking the whole release process and ought to be ignored for testing propagation, etc. Naturally, such entity is the Release Team, and their criteria don't seem bad. * There's not much a DPL could do except some publicity and RFH-oriented efforts which are known not to work well... the apparent solution to the problem is: Porters are an extremely valuable resource, and the survival of an architecture in the distribution is impossible without skilled people who can fix the hardest problems, assist upstream (especially toolchain packages) and Debian maintainers in fixing the issues that prevent a specific arch to meet the release criteria. Therefore, it is essential to preserve, and even grow, such resources by doing all possible to attract people with sufficient knowledge and also pass that knowledge through. (I hope that most of you remember how much insightful Thiemo's analysis about mipsen problems were.) If you managed to keep up reading until this point, my question to the candidates is: What do you think the project should do (with or without or regardless of your help as potential DPL) to preserve this goodness (maximum supported architectures) for as long as possible? Do you think it is goodness or you're in the good riddance camp? Extra question to Wouter as a (former?) porter and buildd admin (feel free not to reply at all; and for other candidates -- feel free to reply if you want to): IMVHO the m68k team was one of the most energetic, enthusiastic and tireless porter teams. It included many knowledgable people who contributed upstream as well (Linux, GCC, glibc, binutils, etc.) The release team made it clear that m68k can return as a release arch at any time, so the kick-out for Etch was (supposed to be) temporary. Why do you think the m68k port is not doing very well (to put it mildly; [*])? [*] It's like the old joke when a person sends a supposed-to-be delicate telegram to a relative: John not feeling well. Funeral tomorrow noon. -- 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/87iq8vys6b.gnus_not_unix!%ya...@gnu.org
Re: Q for all candidates: (Old) Architecture Support
On Wed, Mar 17, 2010 at 03:49:16PM +0200, Yavor Doganov wrote: Debian has been known through the years for its excellent support for many architectures. In theory, a released arch should be as stable as the common/popular archs. (In practice, it is/was pretty close, which is good enough.) This asset is not something to be proud of because of shallow marketing reasons -- it benefits the whole Free World as many bugs are uncovered, reported, and fixed, quite often by Debian people. It would not be incorrect to say that, having in mind how many packages are available in the archive, and the GNU/Hurd + GNU/kFreeBSD ports, Debian is the most comprehensive testground of the GNU system. There is a disturbing and unpleasant tendency (which probably has its roots in the Dark Times, i.e. the Vancouver Proposal) to drop support for some problematic archs as years go by. That's entirely understandable, but: - m68k was the first kicked out arch. AFAICT, it is essentially dead now and not even a miracle can save it. I agree on the stance that it's essentially dead now, yeah. The latter part is not precisely true. If someone were to fix the technical issues with the port that exist today--which would qualify as a 'miracle'--there's a fairly good chance that the port might be resurrected; the m68k porters were always rather enthousiastic about their port. [...list of problematic architectures snipped...] So, having in mind the obvious conclusions a sensible person could do, namely * Support for old (and not only old) architectures cannot be infinite; and there's a line to draw somewhere when it comes to a release. * There should be an entitiy within the project to decide which arch gets released and which not, which one is blocking the whole release process and ought to be ignored for testing propagation, etc. Naturally, such entity is the Release Team, and their criteria don't seem bad. * There's not much a DPL could do except some publicity and RFH-oriented efforts which are known not to work well... Agreed on those points. the apparent solution to the problem is: Porters are an extremely valuable resource, and the survival of an architecture in the distribution is impossible without skilled people who can fix the hardest problems, assist upstream (especially toolchain packages) and Debian maintainers in fixing the issues that prevent a specific arch to meet the release criteria. Therefore, it is essential to preserve, and even grow, such resources by doing all possible to attract people with sufficient knowledge and also pass that knowledge through. I agree. (I hope that most of you remember how much insightful Thiemo's analysis about mipsen problems were.) If you managed to keep up reading until this point, my question to the candidates is: What do you think the project should do (with or without or regardless of your help as potential DPL) to preserve this goodness (maximum supported architectures) for as long as possible? When package maintainers are informed of architecture-specific bugs in their package, they should listen to porters, and actively work on the bug, rather than expect that a porter will fix it (which happens rather often for architectures that are in a problematic state, because it's not a release architecture anyway, thereby only enlarging that architecture's problems). Porters can't fix every architecture-specific bug; and reading unfamiliar code to hunt down why a bug fails on one particular architecture isn't always the easiest thing to do. Of course porters are available to help, since they're supposed to know the architecture, but that's a different matter. Do you think it is goodness or you're in the good riddance camp? I'm clearly in the former camp. Extra question to Wouter as a (former?) porter and buildd admin I'm still a porter; while the m68k port is mostly dead, there are still buildd hosts running that occasionally manage to successfully build something; and that is still uploaded. But these are far and few between. Also, I am an admin for one powerpc host. (feel free not to reply at all; and for other candidates -- feel free to reply if you want to): IMVHO the m68k team was one of the most energetic, enthusiastic and tireless porter teams. It included many knowledgable people who contributed upstream as well (Linux, GCC, glibc, binutils, etc.) Not entirely. There were people who contributed to the upstream kernel, yes. There were no people active in the Debian m68k port on the toolchain. That was one of the reasons of our decline; we had no in-house knowledge to fix our toolchain, and had to rely on outside contributors. I did manage to hunt down a few problems by myself, but it wasn't enough to turn the tide. The release team made it clear that m68k can return as a release arch at any time, so the kick-out for Etch was
Re: Question to all the candidates: communication
Le Sun, Mar 14, 2010 at 10:17:06AM +0700, Paul Wise a écrit : Which project and external Debian-related communications media do you follow? and contribute to? As well as a general list I'm interested in specific lists (for eg #debian, #debian-devel, debian-de...@l.d.o, debian-proj...@l.d.o, the Hardware forum on forums.d.n etc). Hi Paul, Raphael and everybody, For the general lists, I am subscribed to -devel, -project, -devel-announce, -private, -vote and -policy. As part of my packaging activitites, I am also subscribed to -med, -science, -blends and more recently -qa. I also lurk on -powerpc, because I used Debian on a G5 for a couple of years, but I am not really contributing anymore there. Et bien sûr, je suis aussi sur -french et -devel-french. On the web I read Planet Debian, but never visit forums. I do not go on IRC either (too fast for me). I sometimes attend the Tôkyô area Debian study group, but it has become quite rare because I often decide to stay at home to pet my packages instead, or to join a monthly saké-tasting party that often hapens the same Saturday… If I am elected DPL, I will temporarly reduce my activities in the Debian Med project. But I will take more opportunities to meet other DDs in Japan. I will not significatly change my mailing list subscribtions. I will go on IRC if something is planned there, but not on a regular basis. I will use the -devel-announce, -devel, -project and -private mailing lists as main communication channels, and refrain to make fresh announces elsewhere. I will report about the spendings I approved every two months, perhaps on -private if it discloses too much personnal informations, and send a general report every other month on -devel-announce. Lastly, although the atmoshphere improved, I would like our mailing lists even more free from aggression. Things like invitations to stop whining, to change project, and questions about one's mental health hurt, are inappropriate and off-topic, and increase the noise. I will ask the listmasters to not hesitate to ban people for a couple of days if they post a completely useless and aggressive message. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100317143657.ga23...@kunpuu.plessy.org
Re: Q for all candidates: (Old) Architecture Support
Le Wed, Mar 17, 2010 at 03:49:16PM +0200, Yavor Doganov a écrit : * There should be an entitiy within the project to decide which arch gets released and which not, which one is blocking the whole release process and ought to be ignored for testing propagation, etc. Naturally, such entity is the Release Team, and their criteria don't seem bad. Hello Yavor, I do not completely agree with this: I think that the porters should have much more latitude on how to what their port contain. If they can assemble a reasonable subset of Debian's packages into a working system that matches the expectations of the users and that Debian can be proud of. Other teams (security, toolchain maintainers, …) are qualified to tell if releasing a port with that given subset would perturbate their work and therfore the other ports, and the release team would then be the one to take the final decision. I think that a simple reorganisation of our archive's sections and priorities would open the way to such lighter releases. Efforts of developers would be rewarded earlier. Architectures that lose their mainstream position and therfore upstream support in popular heavy-weight applications could survive much longer. As Wouter noted, it is probably when the core toolchain is not maintained anymore that the port is severly compromised. By the way, I would like to react to one of Wouter's comment, that package maintainers should fix the porting bugs themselves. I really disagree. As a pakcage maintainer, I found myself a couple of times in this kind of situation, where nobody wants to do the work. This is a totally fun-killing situation. The port threaten's my package's seat in the release, and my package threatens the port's existence. Yet nobody ever complained that the package is not available for that port… What I mean by my not-so original ‘more fun, more trust’ credo in my platform, is exemplified in this situation by the fact that if nobody wants to fix the bug, it is a good indicator that everybody has more important, more rewarding, and in the end more fun things to do, and that we should trust their judgement by changing our release strategy instead of maintaining an institution that opposes people. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100317150256.gb23...@kunpuu.plessy.org
Re: Question for DD candidates: The race against NOTA
[ quoted text reordered ]
On Tue, Mar 16, 2010 at 10:32:22PM -0600, Gunnar Wolf wrote:
(Yes, quite a hypothetical question. However, if 10-year predictions
are allowed, then mine is too ;-) )
Well, let's not drift too much in that direction, shall we? :-)
(Just kidding, this question is perfectly fine, but I do fear what _can_
happen if we unleash the geek power of posing hypothetical questions!)
What would be different if there was no leader? Where would the
project lose more? Would it gain in some aspect?
In the immediate, we will lose someone taking care of some of the
constitutional DPL duties, like: taking decisions which are either
urgent or for whom no one is responsible, deciding how/if use money
(possibly quickly, due to some urgency), representing Debian with the
external world (i.e. addressing the single voice problem mentioned in
this thread).
Then we will lose an important coordination role that worries about
making people and teams communicate smoothly, even in presence of
personal issues among the involved people (e.g. as intermediary).
Finally and more importantly, we will lose someone that can put into use
an important potential of the DPL role, namely: someone that should
drive discussions when and if needed, someone that should coordinate the
redaction of the project agenda and check periodically if we're on track
or not, and that can use some of our resources to help the project get
back on track if needed (e.g. by organizing specific mini-hack-camps on
technical areas of the project we need to improve).
All in all, I don't doubt the Debian project will survive without a
leader; in fact, it has already happened to us in the past that DPLs
went MIA for unexpected reasons, and we're still here. It would just
be a pity, in the sense that we would renounce to a resource that can
make the project proceed more smoothly than without it.
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: Q for all candidates: (Old) Architecture Support
On Thu, Mar 18, 2010 at 12:02:56AM +0900, Charles Plessy wrote: By the way, I would like to react to one of Wouter's comment, that package maintainers should fix the porting bugs themselves. I didn't mean to imply that, and if it came across as such, I would like to apologise. What I meant to say is that if there is an architecture-specific problem in one of your packages, you should actively work towards its resolution. Sometimes this may mean debugging and fixing it yourself; sometimes this may mean asking a porter to help you with it. But it should not mean (and that was my main point) ignoring the bug because it's not a release architecture, anyway. That happened rather often to the m68k port in its final days on the Debian archives, and it was not helpful. -- 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: Q for all candidates: (Old) Architecture Support
Hi Yavor!
On Wed, Mar 17, 2010 at 03:49:16PM +0200, Yavor Doganov wrote:
This asset is not something to be proud of because of shallow
marketing reasons -- it benefits the whole Free World as many bugs are
uncovered, reported, and fixed, quite often by Debian people. It
would not be incorrect to say that, having in mind how many packages
are available in the archive, and the GNU/Hurd + GNU/kFreeBSD ports,
Debian is the most comprehensive testground of the GNU system.
Absolutely, it is one of our distinguishing values that we should
cherish more than we currently do. FWIW, there is nothing wrong in
using it _also_ for marketing reasons. In general, the kind of marketing
based on our distinguishing features (and this is one of those) is our
best chance to attract new contributors.
- m68k was the first kicked out arch. AFAICT, it is essentially
dead now and not even a miracle can save it.
That is was kicked out by the current rules is true (actually, that is
what it seemed to me as a DD non-porter, people like Wouter surely knows
more than me about extra details, if any). What I don't share of this
sentence is the feeling of causality it gives between being kicked out
and then dying.
I sure do not want to deny that a non-release arch is looked at by less
eyes, and that the project in general cares less about it (e.g. as the
bugs are not RC, they are less likely to be NMU-ed). But an architecture
which is suffering anyhow---for instance no maintenance of the toolchain
or no buildd admins for it---would not necessarily be any better
supported for end users. Also, the process of arch qualification goes
both ways, and the entrance of GNU/kFreeBSD as a new release arch is IMO
evidence of that. In fact, if the above impression of causality were
true, we would risk to be stuck to not having new archs in the future,
which luckily is not true.
Ultimately, I believe that when an average package (i.e. not a monster
package) is properly maintained, the maintainer will be happy to apply
patches that add support for an arch, even if it is not (yet) a release
arch. You might argue that there are several average packages which are
not properly maintained, but that's a whole different problem ...
* Support for old (and not only old) architectures cannot be infinite;
and there's a line to draw somewhere when it comes to a release.
* There should be an entitiy within the project to decide which arch
gets released and which not, which one is blocking the whole release
snip
* There's not much a DPL could do except some publicity and
RFH-oriented efforts which are known not to work well...
AOL
I was thinking along the same lines while reading your post thus far,
thanks for sparing me to write these :)
Porters are an extremely valuable resource, and the survival of an
snip
Therefore, it is essential to preserve, and even grow, such
resources by doing all possible to attract people with sufficient
knowledge and also pass that knowledge through.
Agreed.
What do you think the project should do (with or without or regardless
of your help as potential DPL) to preserve this goodness (maximum
supported architectures) for as long as possible? Do you think it is
goodness or you're in the good riddance camp?
I'm surely on the goodness side. More generally, I'm for defending and
advertising more all of Debian distinguishing features, and our range of
supported archs is surely one of them.
On the side of developers, ideally we should not accept maintenance
behaviors in which patches that add support for non-release archs are
regularly ignored, but that can hardly be imposed to people. Let's just
aim for packages which are in a good maintenance status (more QA, as
usual) and I believe that more reactivity to porters patches will come
for free.
On the side of porters, we cannot create them magically. All we can do
is (1) do our best to attract them (because we know such rare entities
do exist :-)) and then (2) put them in the best possible condition to do
what they like. To improve their work condition I fear the DPL can do
little more than ensuring our arch-specific machine park is up to par.
To attract them, advertising arch support as I said above would be a
wonderful start.
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?
Le Mon, Mar 15, 2010 at 08:13:23AM +0100, Raphael Hertzog a écrit : What do you think of this and would you be ready to withdraw a delegation for a delegate that behaved badly towards another DD (even outside of his delegated role), that has been warned once by you and that did it again later on? Do you think we can draft a code of conduct for Debian and do you think you can ensure that it would be respected by delegates? Dear Raphaël, the role of many delegates is to lead a team, and as such they need good social skills. Biting back people who criticize their work is not a good way to defend their team. In contrary, it turns down contributors and isolates it. I would like to add that aggression is not the only bad behaviour. Refusing answers is also a way to demotivate and put aside people. I think that the role of a delegate is to communicate even with the developers he does not want to work with. (If some people abuse the delegate's time with repetitive requests, that is another story). If a delegate repeatedly misbehaves or fail to communicate, I will ask him to step down in a mid/short term, ideally at the opportunity of a notable achievement. I think that it is important to leave to people a possibility to save the face, expecially with on-line projects like Debian that leave a permanent trace in the Internet search engines. Changing a delegate should not be a personal punishment, but a way to get things done better in Debian, so despite that “we will not hide problems”, I will not have the discussion with the badly behaving delegate in public (but perhaps on debian-priv...@l.d.o if I have the feeling that the Project is expecting it). Lastly, I do not think that we need a code of conduct. I am worried that it would generate too much meta-discussion. I think that it it enough to remind newcomers that when we do not know personnaly the recipient of our messages, there is a high risk that anything too causal will be misinterpreted. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100318011536.ga18...@kunpuu.plessy.org
Re: Question for all candidates: Release process
On Wed, Mar 17, 2010 at 12:56 AM, Gunnar Wolf gw...@gwolf.org wrote: Hmm, you got me thinking here on why this happened, as I share your impression. Maybe it was because the project as a whole put more care into the release process after the massive pain it was to release Sarge, a three-year-long pain we didn't want to suffer again? For Lenny we lost some of that push, although the release process was still mostly swift, with a minor slip regarding what we expected. As has been said by others, I don't think this is accurate. It might have been one of the reasons, but there are probably many others. For example, the competition of dunk-tank vs dunc-bank, made Etch one of the best Debian releases because it REALLY had very very few bugs. In other releases, there might have been no RC bugs reported, but the bugs were there anyway. Another thing that I see special about Etch, is that Steve and Andreas stayed as managers after Sarge was released, so they came to Etch with a lot of knowledge on their shoulders. After that, it has been sadly very hard for us to keep the RMs for long enough. And there are probably a lot of other factors to take into account of Etch's success. As for the reasons why we are not freezing yet... I think it is somewhat a lack of commitment to what the Release Team says, as (too) many people felt betrayed with the way the freeze-related announcements were made (a topic that has already been analized here). I don't agree here. I think that the lack of commitment to the release is more probably due to lack of enough communication from the Release Team and lack of motivation from the general developer body. This is not intended as criticism towards what the RT has done, but it's more of a diagnose: we are lacking motivation and more communication of near-future goals could help us work better as a group. Personally, even though I was shocked in July by the unexpected announcement, I was very glad to see the Release Team find a compromise solution, that fit the project's time better, and thus in no way do I feel betrayed. I don't think the majority of developers does. I think that the lack of manpower is a much bigger factor. As has been said, here and elsewhere, we are lacking people on this area as much as on many other areas in Debian, and that shows. So, going back to the questioning of the candidates: Do you agree with this very simplistic analysis? If so, how would you push to get the drive and the confidence back? As said, I don't agree. What I plan to do as DPL that would help in this area, is set some project-wide goals, so that developers can be inspired to focus their energies on those goals, and also several initiatives to get more people to help Debian, both by reporting and by fixing bugs. -- 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/e8bbf0361003171822k5f26d409ma77ed9c07e962...@mail.gmail.com
Re: Question to Candidates: Disappearing DPLs?
On Tue, Mar 16, 2010 at 4:30 AM, Gerfried Fuchs rho...@deb.at wrote: I have a question to the candidates: History has shown that DPLs more or less disappear not too long after their period or at least reduce their visible efforts immensly. I wonder where you see the reasons for this trend, what your impression is about it and wether you try to follow that trend or what you will try to do to not have this happen to you, too. As has been stated by people previously holding the DPL role, it's a very time consuming task, which tends to take away quite a lot of that person's time. Thus, I feel it as only natural to want to have a break to catch back with all the stuff that had to be relegated during the DPL term. I don't necessarily view it as a bad thing. Sometimes, taking a sabbatical means being able to come back to keep working on the project with renewed energies... Unfortunately, it also sometimes means completely disappearing from the project. Debian plays a very central role in my life, so no matter how burned out I could become, I would not totally disappear after the term. However, I'd like to prevent the burning out as much as possible. For that to happen, I intend to delegate a lot. I don't intend to be a solo leader. For all the initiatives that I plan to do, I'd first form a team of people and work with them into putting the ideas into action. -- 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/e8bbf0361003171835h77f500bfm2c96a2df20336...@mail.gmail.com
Re: Question for DD candidates: The race against NOTA
On Wed, Mar 17, 2010 at 1:32 AM, Gunnar Wolf gw...@gwolf.org wrote: What would be different if there was no leader? Where would the project lose more? Would it gain in some aspect? The Constitution gives the DPL a number of duties that would then be vacant. Even though it wouldn't necessarily lead to total chaos, having no one to decide what to do with Debian's money, no one to appoint the necessary delegates when some of them resign, and no one to be the central voice to speak for Debian, could be quite problematic. It could be possible to resort to many more GRs than we are currently having, and vote on everything that has to be decided, but it wouldn't be a good productive use of everybody's time. Mainly, the DPL is the role of a person capable of inspiring all the developers into working together towards a common goal. By losing the DPL role, we would lose the chance of really being a united community and become separate individuals working on separate stuff. I do not kid myself, I know that many times that's what we are, but still I think that the leader helps keep us more or less on track. I can't think of any advantages of having no leader. I second zack's request to please not continue with this hypotheticals, please, I'd rather use my brain to think about real problems and the solutions needed. -- 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/e8bbf0361003171851j2a6aeb9ev18c4608498e5b...@mail.gmail.com
Re: Question for DD candidates: The race against NOTA
Toni Mueller dijo [Wed, Mar 17, 2010 at 11:27:57AM +0100]: What would be different if there was no leader? Where would the project lose more? Would it gain in some aspect? I am not a candidate, but I can immediately see that the press would take the voice of random DDs as the voice of the Debian project in cases when it wants a statement. As we were not unanimous on many issues in the past, just imagine what if one of the people who are no longer around would have been able to make official statements on behalf of Debian. I bet that this could become quite interesting. ;} Of course - But we do have a press team. If we were to lack a Leader, the press team would just become the contact point for the press, right? (note that I am not against the DPL position, I am just entertaining the idea) -- Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244 -- 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/20100318050732.gf27...@gwolf.org
