Re: Question for all candidates: Release process
(And to answer to the comment ‘you do not need to be DPL for doing this’, that is true, but if I make a bad score at this election, I will conclude that there are not many persons interested in what I propose anyway, and will save everybody's time by not discussing them further in the short term.) Now, I think thats the wrong conclusion. While it should be pretty known that I am not really a fan of you getting DPL, I have one remark about the above: - A good idea should (unless its constitutional required, but what is?) not be bound to a DPL term. - A lost election might not mean that the ideas are all bad. (It can mean it). It might just mean they are presented wrong, or that everyone thinks they got presented wrong/at wrong time/at wrong place. -- bye, Joerg I'm not a bad guy! I work hard, and I love my kids. So why should I spend half my Sunday hearing about how I'm going to Hell? -- 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/8739zjlhra@gkar.ganneff.de
Re: Question for all candidates: Release process
Le Mon, Mar 29, 2010 at 11:03:00AM +0800, Paul Wise a écrit : I find that attitude problematic. When electing a DPL we get a package deal. Some of each candidates ideas are liked by some/many, others disliked by some/many. It would be a shame to throw out good ideas with bad ones. Le Mon, Mar 29, 2010 at 09:16:41AM +0200, Joerg Jaspert a écrit : - A good idea should (unless its constitutional required, but what is?) not be bound to a DPL term. - A lost election might not mean that the ideas are all bad. (It can mean it). It might just mean they are presented wrong, or that everyone thinks they got presented wrong/at wrong time/at wrong place. Hi Joerg and Paul, you are completely right, and that why I moderated my comment by finishing it with ‘in the short term’ :) Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100329072751.ga4...@kunpuu.plessy.org
Re: Question for all candidates: Release process
* Charles Plessy ple...@debian.org [100327 06:17]: I think that the ‘RPM hell’ that you used to comment my propositions is more related to a situation when independant distributions are using the same package format, than when a distribution offers multiple repositories that obey to a policy that keeps the whole system functional. Even repositories from the same project tend to diverge enough that everything fails apart from a user perspective. One of the biggest practical advantages of Debian is that there is one Release of virtually everything. Everything fits and no incompatiblities of the different 'unimportant' things (Remember what is unimportant for the general is still important for most the people using it). Thus splitting the archive in core and non-core can at worst create multiple diverging no longer matching repositories for the different tasks. And at best causes one core system freezing earlier and then all the rest freezing based on that, which is something Debian already tried without splitting things apart and I got the impression people did not think that lead to anything but problems. Regarding my proposal, that is internal to Debian, I do not think that it is impossible. What I propose is a way for package maintainers to signal that their package is peripheral in the Debian system, in an opt-in manner. Debian is running out of manpower, and I think that it will be useful to let know that a given package can be given a low priority for tasks. We lack manpower in core tasks. In the packages that are too big to fail. People never had much problem to keep packages unimportant for the general out of releases (even to the point of packages I miss desperately). Some system to direct focus might be nice, but I really doubt it would change things much. Anyone with a little bit of knowledge knows what the core packages are and that fixing those is more important. You can't tell me that the hordes of gosh, there is a bug in some little game that is RC since 3 days, with a one-line fix that is already in all VCSes but in no package because there was no upload for a year, let's NMU fast people will suddenly stop reaching for low-hanging fruits and instead look at bugs that cannot be fixed without looking for at least a week at it? Our current priority system does not fit that task. Because of the rules about conflicts, important packages like postfix are of priority extra. How is postfix important? It's not installed by default, the majority of people does not need it. It may be important to you and many other people, but virtually every package is important to at least one person. With a priority system improved along this direction, I think it opens the possibility to let some architectures release without the least important packages. What is let some architecture release supposed to mean. Being subscribed to some architecture specific lists, I cannot remember people active for some architecture ever requesting they do not want some package. Usually that is the maintainers of the packages that complain that those architectures are not enough like i386 to simply choke code that should never had been open source because even the possiblity that a human would look at it is a crime against humanity. Not having some package in some architecture makes that architecture much less attractive, because differences suck. Most people having more than stuff still booting in 16 bit mode usually have multiple architectures. Having one Debian that is the same everywhere is a very big advantage from the point of the user. I cannot imagine some architecture no longer wanting that, because that would mostly be suicide. So is this let supposed to mean allow or to mean force? We also already have a possiblity to release without some package on some architecture. Just stop building it and request removal from unstable. There is a reason we frown upon this. Building stuff everywhere and make it work everywhere is a big investment in quality and making things fit for the future. I doubt without years of fixing bugs everywhere to make things work on alpha (which could be seen to be mostly an architecture born dead in a commercial sense quite early), introducing amd64 could have been done thus smootly as it comparatibly was. And all those alignment issues on most architectures usually also speed up code in i386 if fixed properly... Hochachtungsvoll, 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/20100328105131.ga6...@pcpool00.mathematik.uni-freiburg.de
Re: Question for all candidates: Release process
Le Sat, Mar 27, 2010 at 01:15:47PM +0100, Stefano Zacchiroli a écrit : I don't understand what cloud computing has to do with your idea of using package priorities to release differently different sub-systems within Debian. I'm well aware that we are currently lagging behind in the race for OS for the cloud (and we should really catch up, at least in terms of visibility), but what it has to do with your idea? Hi Stefano, I think that cloud computing participates to create the demand for a Debian system that offers not only a stable release that lasts years, but also updated packages that are built or collected for being used with the stable release. A mirror containing stable, backports, and snapshots is a good first step in that direction. The problem of having all backports in one single repostitory is of course that not all packages have the same needs, which creates incoordinations or conflicts of interest. Again, I am not saying that it will be the silver bullet, but a refactored priority and sections system would allow to easily identify subsets that could have a common policy and an increased effort for coordination, or in contrary a more unsupervised mode of operation when it comes to leaf packages (trust the maintainers!). I do not pretend to offer a complete and robust solution in my platform or the emails discussed on this list. But I ask the question to the DDs: would you like to distribute your work differently? If yes, vote for me as a DPL, and will spend time and energy to help the Project go that way. (And to answer to the comment ‘you do not need to be DPL for doing this’, that is true, but if I make a bad score at this election, I will conclude that there are not many persons interested in what I propose anyway, and will save everybody's time by not discussing them further in the short term.) Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100329015024.gb4...@kunpuu.plessy.org
Re: Question for all candidates: Release process
On Mon, Mar 29, 2010 at 9:50 AM, Charles Plessy ple...@debian.org wrote: (And to answer to the comment ‘you do not need to be DPL for doing this’, that is true, but if I make a bad score at this election, I will conclude that there are not many persons interested in what I propose anyway, and will save everybody's time by not discussing them further in the short term.) I find that attitude problematic. When electing a DPL we get a package deal. Some of each candidates ideas are liked by some/many, others disliked by some/many. It would be a shame to throw out good ideas with bad ones. -- 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/e13a36b31003282003r60f47ee4n69a459f9606b0...@mail.gmail.com
Re: Question for all candidates: Release process
Hello Bernhard and everybody, I think that the ‘RPM hell’ that you used to comment my propositions is more related to a situation when independant distributions are using the same package format, than when a distribution offers multiple repositories that obey to a policy that keeps the whole system functional. We actually enter in the era of the ‘DEB hell’ since the success of Ubuntu, with users asking support for cross-distribution package installation. In the end, it is more a communication problem than a technical problem. We should make it clearer that it is not because the packages do not carry the distribution name that they are not specific to a distribution. Perhaps a page about ‘our packaging system’ for end-users on our website? Regarding my proposal, that is internal to Debian, I do not think that it is impossible. What I propose is a way for package maintainers to signal that their package is peripheral in the Debian system, in an opt-in manner. Debian is running out of manpower, and I think that it will be useful to let know that a given package can be given a low priority for tasks. In my experience, trivial RC bugs on not-so important packages attract volunteers because it is very rewarding to close RC bugs. Also, I learnt a lot by participating to the ‘bug sprint’ organised by Josselin for Lenny, that we should not be discouraged to challenge a bug that is far beyond our technical capacities, because help like triaging and pinging the reporters is very useful and frees skilled hands that are much more useful at other tasks. So in my opinion, not all RC bugs are equal, and a better priority system would be useful to help volunteers to chose their focus. Our current priority system does not fit that task. Because of the rules about conflicts, important packages like postfix are of priority extra. By refactoring our priority system, we could make a much better usage of a priority level that really means ‘extra’ in the sense of ‘do not bother if you have more important things to do’. With a priority system improved along this direction, I think it opens the possibility to let some architectures release without the least important packages. Once I reported upstream that his scientific software was not working on Sparc. ‘I know‘, was the answer. This software, I want to bring it to the scientific communauty, and like the upstream author, I know that no researcher is seriously considering running it on Sparc for work. Why not distributing it only on amd64 until a user requests it on another architecture? Even on the other platforms where it builds, I have no clue if it works. And in my experience, the more regression tests I enable in my packages, the more I realise that they do not work on the platforms that neither upstream nor the users are using. I am very tempted to go even further and would like to distribute some packages for the stable distribution only through official backports for instance. Also, in my field, while people usually want to have the latest version to start with, they also do not want to change in the course of their analysis. I hope that the future package snapshot system will help us to satisfy this need. In conjunction with system image builders, Debian pure blends and ‘cloud computing’, it will be very powerful. Will it make the release easier? I think so, even if it is definitely not a magical wand. It transfers some responsabilities, and the work load that comes with, from the release team and the porters to the maintainers of leaf packages of low priority. I would like the Debian project to trust more its maintainers, and allow this transfer. Have a nice week-end, -- Charles -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100327061703.ga28...@kunpuu.plessy.org
Re: Question for all candidates: Release process
On Sat, Mar 27, 2010 at 2:17 PM, Charles Plessy ple...@debian.org wrote: Regarding my proposal, that is internal to Debian, I do not think that it is impossible. What I propose is a way for package maintainers to signal that their package is peripheral in the Debian system, in an opt-in manner. Debian is running out of manpower, and I think that it will be useful to let know that a given package can be given a low priority for tasks. In my experience, trivial RC bugs on not-so important packages attract volunteers because it is very rewarding to close RC bugs. Also, I learnt a lot by participating to the ‘bug sprint’ organised by Josselin for Lenny, that we should not be discouraged to challenge a bug that is far beyond our technical capacities, because help like triaging and pinging the reporters is very useful and frees skilled hands that are much more useful at other tasks. So in my opinion, not all RC bugs are equal, and a better priority system would be useful to help volunteers to chose their focus. Does popcon not already provide a way to order packages based on importance? rc-alert has both options for sorting bugs by both local global popcon score. If not, what criteria would you suggest we use to prioritise RC bugs? Should we change bts.turmzimmer.net to use that for ordering? -- 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/e13a36b31003270113p5ec3a20ew8570cbb19e23d...@mail.gmail.com
Re: Question for all candidates: Release process
On Sat, Mar 27, 2010 at 03:17:03PM +0900, Charles Plessy wrote:
In my experience, trivial RC bugs on not-so important packages attract
volunteers because it is very rewarding to close RC bugs.
snip
So in my opinion, not all RC bugs are equal, and a better priority
system would be useful to help volunteers to chose their focus.
Absolutely: not all RC bugs are equal, there are easy and hard ones.
Letting aside truisms like they should all be fixed anyhow, the
problem is that how much they are difficult to fix depends on who
approaches them (which might well be another truism), so you can't
really prioritize bugs, for release purposes, according to how difficult
they are.
Also, in my field, while people usually want to have the latest
version to start with, they also do not want to change in the course
of their analysis. I hope that the future package snapshot system will
help us to satisfy this need. In conjunction with system image
builders, Debian pure blends and ‘cloud computing’, it will be very
powerful.
I don't understand what cloud computing has to do with your idea of
using package priorities to release differently different sub-systems
within Debian. I'm well aware that we are currently lagging behind in
the race for OS for the cloud (and we should really catch up, at least
in terms of visibility), but what it has to do with your idea?
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
Le Sat, Mar 27, 2010 at 04:13:11PM +0800, Paul Wise a écrit : Does popcon not already provide a way to order packages based on importance? rc-alert has both options for sorting bugs by both local global popcon score. Hi Paul, Popcon is definitely a potent indicator, but has its flaws as well. After all, the median popcon score of Debian's ports is quite low, and we give them a lot of importance. I think that adding priorities in the equations can be useful, but after reorganising them, because for the moment, a very large majority of RC-buggy packages are of priority ‘optional’, which does not tell much. Of course, I am not campagning on that detail (the priorities), but more on the fact that we can try other release strategies, and I think that refactoring the priorities would open more possibilities. That is the main motivation for me to give this example. Should we change bts.turmzimmer.net to use that for ordering? That is really up to the bts.turmzimmer.net users. When I use it, i just go in alphabetic order and evaluate priority myself… Bapase could a nice addition, for people like me who are more on the removal mood. Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100327153759.ga31...@kunpuu.plessy.org
Re: Question 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. We already do that, provided the RC bug is old enough. This (and other parts of your answer) show clearly that you don't know how the current release process works (and also didn't read our mails on debian-devel-announce). BTW, fixing of RC bugs is not done by the release team, but (thanksfully) by a large group of Debian Developers; of course also members of the release team fix RC bugs :) Andi -- 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/20100324091605.gr19...@mails.so.argh.org
Re: Question for all candidates: Release process
Le Mon, Mar 15, 2010 at 08:09:19AM +0100, Lucas Nussbaum a écrit : During the last debconf, the freeze of squeeze was first announced to take place in December, then this decision was cancelled, and now we are in March. - How do you analyze what happened during last summer? What went wrong? - What is your opinion on the motivations for the proposal to freeze in December? Specifically, in the future, should we try to coordinate our release process with Ubuntu's? - So, we are now in March. What is your opinion with the release process so far? When do you see the release happening? Hi Lucas, I was really disapointed when I read the press release. After announcing a decision to the public, it is very difficult to change it; it really gave me the impression to have my arm twisted. The freeze of Lenny was quite long, and I tried to play the game, not updating my packages but doing release-oriented work (including some tasks very specific to Debian Med, which did not have an impact on Lenny's releasability). As a consequence, I was very worried that I would not be able to update my packages to all the new upstream releases that happened during the freeze, if we would freeze again in December. This said, I am well aware that all my packages are not essential to Debian's life, and I decided to not complain too much and trust the judgement of the release team. However, my personal opinion was that it is not a good idea to release Debian with packages less up to date and a shorter security support than Ubuntu. I would rather release on the years where there is no Ubuntu LTS. This way, people trained to use dpkg-based distributions have the opportunity to install a recent release with a reasonably long support each year, instead of each second year. I think that this would maximise Debian and Ubuntu's user base. In this elections I propose to change our release philosophy. Depending how oftern the kernel, libc, GNU, GCC, X.org, and other bright software stars align in the sky, it could mean that we could release a core distribution more often (than each second year) if we were interested in committing to this effort. Still, a synchronisation with Ubuntu is taking the problem in the wrong direction, I think. I do not have a long experience in collaborations with Ubuntu but it seems that to meet deadlines, they do not hesitate to diverge with upstream projects much more than what we are used to. I do not think that we shall follow them in this path. I see more collaborations made on opportunity basis, when both distribution's choices are naturally converging. We can not promise to be ready to release the 1st of April 2012. Now we are in March and I do not know when we will release. For the Lenny release, with the release goals, the progressive freeze and information emails from the release team, we went through milesones that I think helped a lot the Project have a good feeling of the timing. The last footstep took more time. It was written often that it is because there were too many RC bugs, but I think that the true reason is that we were waiting for the installer team. I do not write this to throw a stone to them, but to repeat once again that fixing abandonned package does not make the release closer [but if you have fun with this, do not stop! Debian is also about having fun]. Turning the spotlights on the most difficult blockers would be very helpful. I do not know if we can release soon, in the sense that I do not know if the packages providing the core functionalities of our operating system are ready. Honestly, as a DD I am not interested to fix bugs like python packages that do not work with version 2.6 if the maintainer does not at least ask for help (I would rather be interested to participate to bolder package removal sessions). If many other DDs share the same impression, and if all RC bugs are left in the same bag without indication of priority, then we probably will not release soon. Milestones like freezing the toolchain would send a strong message that it is time to refocus our efforts from our own packages and team to the last blockers. Since the original plan was to release with Ubuntu LTS and that will not be done, as a DPL I would ask the release team to update the project on its plans. Have we lost the announced benefits of a joint release and postopone for more than a couple of months to allow more developments, or are we very close to freeze our core toolchains anyway ? Frans Pop wrote an insightful email on how the release is also a lot of communication work. If I am elected DPL, I will emphasise this role in the delegation given to the release managers. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100319012849.ga1...@kunpuu.plessy.org
Re: Question 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: 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: 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 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 for all candidates: Release process
Le Sun, Mar 14, 2010 at 02:44:15PM -0700, Russ Allbery a écrit : Releasing is regularly the hardest thing that Debian does, not just technically but also socially. Apart from the standard issues of setting deadlines, RC bug counts being high, and similar difficult technical issues, the process seems to eat volunteers. Dear Russ and everybody, I think that our release process is manpower-hungry by design, and that the more packages and architectures we have, the harder the release is. I propose to refocus our efforts. Solving a thousand of RC bugs is a herculean task for a small group of persons. But why should they do that in the first place? Most of these bugs are the responsibility of the package maintainers. If they can not make their package ready for the release, will they be able to help for stable support? Who will do that work? I propose that we reshape the sections and priorities of our archive, so that it is easy to remove from Testing any RC bug that is not in a core pakcage, and is old and not tagged RFH. In parallel, I propose that the definition of what the ‘core’ is can vary between architectures. The goal is not only to reduce the workload of the release team and the porters. It is also to give some meaning to the presence of a package in a stable release. These packages must be there because there is agreement that enough users are insterested in it, and are comfortable with the idea to keep it at the same version for a long time. For many peripheral leafs and branches of our dependancy tree, let's innovate and distribute them through other channels, like official backports and even the new snapshot system that is being set up. When all of this is aptable from the official Debian mirrors, it will open great opportunities to build tailored Debian systems, for instance with the ‘blends’ framework. Debian is volunteer-driven, so the release can only happen by coordination. Acutally, it is a coordination process by nature: a release is a moment in the development where all the core components work well together. If these components evolve independantly, it will hardly happen by chance. Motivation must be there on both ends. This is why I propose to limit the release to the packages where there is a real motivation for it. When maintainers feel the need for a release, they will have to talk to the others and eventually make concessions on their timeline. Not to mention that for many of our packages, there is actualy nobody who regularly cares for them anymore. In that sense, I think that membership issues are one of the roots of our difficulties to release. As a DPL I will help the Project to evolve its release and membership process through my constitutional roles: leadership in discussions, GRs, and delegations. I expect as a result that the release work will become much more social than technical, with all participants doing their part of the housekeeping work. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100317005207.ga6...@kunpuu.plessy.org
Re: Question for all candidates: Release process
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. 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). 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? -- 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/20100317035655.gb13...@gwolf.org
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
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: 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 elen...@planet.nl 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
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 TS). 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: 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 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
