Re: Question for all candidates: Release process

2010-03-29 Thread Charles Plessy 
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

2010-03-29 Thread Joerg Jaspert 

> (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

2010-03-28 Thread Paul Wise 
On Mon, Mar 29, 2010 at 9:50 AM, Charles Plessy  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

2010-03-28 Thread Charles Plessy 
Le Sun, Mar 28, 2010 at 12:51:31PM +0200, Bernhard R. Link a écrit :
> 
> So is this "let" supposed to mean "allow" or to mean "force"?

Hi Bernd,

it means, the one who wants the package is responsible for it. If upstream and
the maintainer are not interested in supporting a package on an architecture,
and if the porters want the package in their portfolio, then it would be their
responsability to deal with the porting issues. In contrary, if the maintainer
wants the package on an architecture, and the porters are busy with other
tasks, then it would be the responsibility of the maintainer to find help
somewhere else. I do not mean to force people. For the moment the forced people
are the maintainers who have to spend time on architectures where their package
is not used.

This would be much clearer than having three parties that try to throw the hot
potato in each other's hands.


> 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...

This is very true, and will provide a motivation for building the package on
non-mainstream architectures, but where my opinion differs is that looking for
new bugs is a task for upstream, not for the pakcage maintainer. I am most
happy to assist upstream in this task, but the motivation has to come from him.


Have a nice day,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100329020628.gc4...@kunpuu.plessy.org

Re: Question for all candidates: Release process

2010-03-28 Thread Charles Plessy 
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

2010-03-28 Thread Bernhard R. Link 
* Charles Plessy  [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

2010-03-27 Thread Charles Plessy 
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

2010-03-27 Thread Stefano Zacchiroli 
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.

> 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

2010-03-27 Thread Paul Wise 
On Sat, Mar 27, 2010 at 2:17 PM, Charles Plessy  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

2010-03-26 Thread Charles Plessy 
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

2010-03-24 Thread Andreas Barth 
* 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

2010-03-18 Thread Charles Plessy 
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

2010-03-17 Thread Margarita Manterola 
On Wed, Mar 17, 2010 at 12:56 AM, 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.

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

2010-03-17 Thread Stefano Zacchiroli 
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

2010-03-17 Thread Wouter Verhelst 
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

2010-03-17 Thread Bernhard R. Link 
* Charles Plessy  [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

2010-03-16 Thread Gunnar Wolf 
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

2010-03-16 Thread Charles Plessy 
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

2010-03-15 Thread Frans Pop 
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

2010-03-15 Thread Wouter Verhelst 
On Mon, Mar 15, 2010 at 08:09:19AM +0100, Lucas Nussbaum wrote:
> On 14/03/10 at 14:44 -0700, Russ Allbery wrote:
> > This is for all candidates.
> > 
> > Releasing is regularly the hardest thing that Debian does, not just
> > technically but also socially.  Apart from the standard issues of setting
> > deadlines, RC bug counts being high, and similar difficult technical
> > issues, the process seems to eat volunteers.  There's usually always at
> > least some frustration, anger, and upsetness, and there seems to usually
> > be at least one resignation over the course of a release, often in a way
> > that hurts other activities in Debian for a time.
> > 
> > Do you have any ideas how, as DPL, you would (or even could) address this?
> > I'm personally the most concerned with the social issues.  A delayed
> > release can be frustrating but doesn't have that much negative impact, but
> > volunteers with enough knowledge of Debian to be able to serve as release
> > managers or helpers are rare.  And usually the arguments not only hurt
> > their contributions to Debian but usually hurt the contributions to Debian
> > of the people on the other side of the argument as well, who are often
> > also valuable and difficult-to-replace volunteers.
> > 
> > Do you have any thoughts about how to resolve release issues with less
> > hurt and negative impact to the project all around?
> 
> Three more release-related questions.
> 
> During the last debconf, the freeze of squeeze was first announced to
> take place in December, then this decision was cancelled, and now we are
> in March.
> - How do you analyze what happened during last summer? What went wrong?

From my perspective, it looks like some people jumped the gun a little,
though with the best of intentions.

> - What is your opinion on the motivations for the proposal to freeze in
>   December? Specifically, in the future, should we try to coordinate our
>   release process with Ubuntu's?

I don't think it hurts anyone for Debian to cooperate with another
project, be that project Ubuntu, the FSF, or something else.

If the cooperation with Ubuntu worked well for this release (I am not
very up-to-date on the details here), then I see no reason why we should
not do so.

> - So, we are now in March. What is your opinion with the release process
>   so far? When do you see the release happening?

In my opinion, the best release we ever had (that I was a part of, at
least) was the Etch release process; shortly after Sarge had been
released, the release managers had started to regularly update the
project as a whole on where we were in the process, and I believe that
worked very very well. During the whole of the Etch release process,
there was never really a point in time where I felt I didn't know how
far away the release still was.

It feels to me as though the frequency and/or quality of updates has
reduced somewhat since the Etch release, though I'll readily admit that
that is just a gut feeling. At any rate, I do not feel I am as
up-to-date as I was during the Etch release process on when the release
is going to happen. I don't think it's going to take more than, say,
half a year, though.

> (I'm fully aware that the DPL is not in a position to take many actions
> regarding the release. However, similar questions are likely to be asked
> during post-election interviews, so we would better know how you will
> answer ;)

Hope that answers that,

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


signature.asc
Description: Digital signature

Re: Question for all candidates: Release process

2010-03-15 Thread Wouter Verhelst 
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

2010-03-15 Thread Stefano Zacchiroli 
On Sun, Mar 14, 2010 at 02:44:15PM -0700, Russ Allbery wrote:
> Releasing is regularly the hardest thing that Debian does, not just
> technically but also socially.

To some extent, I believe it is normal. Releases are our main
"products", they define our purpose. The people which are putting their
names in driving the release process, i.e. the members of the release
team, are very tightly bound to the release process. The closer we get
to a release, the closer they might feel pressure, which sometimes has
unfortunate consequences.

My impression is that most impromptu resignations in Debian happen as a
consequence of some form of burn-out, which are unfortunately not
uncommon in volunteer FOSS projects. I don't believe the release team
constitutes an exception to this unfortunate rule.

A general cure to this is to avoid people taking over their shoulders
more responsibility than they can handle. I was very positively
impressed when Steve McIntyre's team review of two years ago found out
people involved in an incredibly high number of Debian teams and
actually incouraged those people to step back from some of them. We
should encourage DDs to periodically review their involvements and focus
their energies on a few specific areas. Being a member of the release
team, or even the release manager is, again, no special case.  As it is
hard to actively state "I step back", we should also more frequently do
(self-)appointments with an attached "expiry date", when the date
expires the involved people can "snooze" it actively or just let others
know that it is time for them to move on to Debian activities which are
more fun for them.

> Do you have any thoughts about how to resolve release issues with less
> hurt and negative impact to the project all around?

On one hand, I believe that the pressure on, and even some personal
conflicts with, the release team could have been much lower in the past
(generally, not necessarily only in this last release process) with a
bit more communication with project. As a DPL, I would generally prod
the release team for periodic status reports (at least monthly) which
are much needed, considering the peculiar role of the release process in
Debian. If prodding is not enough, the DPL can also take care of the
communication him/herself.

On the other hand, I think the release team has felt in the past more
than a bit of frustration, due to the apparent disinterest of DDs in
getting a release done. I particularly remember during DebConf8 (Lenny
release cycle) a deserted BSP which was largely perceived as lack of
interest in getting the RC bugs count down. That is just an example and
maybe not even the most appropriate one [1], but the problem exists:
beside maintainers that don't care about fixing RC bugs in their
packages, not so many people care about helping in releasing Debian, by
working on packages other than theirs. That can easily make the release
team feel "alone against the release", which is surely not a productive
context to work in.

Ultimately, I believe this is a cultural problem that will take us quite
some time to fix. I'm aware of various initiatives in the right
direction:

- use the NM process to coach newbies about the importance of fixing
  packages other than theirs (we already request to provide RC bug
  patches during T&S). I personally had very good responses on this from
  a couple of NMs which started patching and/or NMU-ing RC-buggy
  packages with (proper) patches just after becoming DDs

- more generally, diminish strong package ownership by communicating
  that contributions like NMUs are good, as long as they are done
  following the rules (initiatives like RCBW and its predecessors
  attracted quite a lot of "minions", for instance)

The ideal bottom line of this is that, if the DD body starts feeling
more part of the release process (rather than only thinking at their own
pet packages), then DDs will more and more stand on the side of the
release team, rather than against it.

Cheers.

[1] one can argue that a DebConf should better be used in other ways, etc

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Question for all candidates: Release process

2010-03-15 Thread Margarita Manterola 
Hi Frans,

Let me first start by stating that I'm sadly concerned about the tone
of your mail.

Nobody claims that the release process has been done perfectly, there
have been mistakes, but we are all human and we can all make mistakes.
 It's alright to point those mistakes out so that people can correct
them, but I find your mail disturbing, because it feels more like
attacking the past Release Managers than trying to improve the overall
project quality.

With that in mind, I'll answer only a few of the issues you raise,
those that I feel are relevant to the upcoming election.

On Mon, Mar 15, 2010 at 12:30 PM, Frans Pop  wrote:

> The Release Team should IMO keep in mind that it's not *they* who make a
> release, but the whole project together. And the best way to get respect
> for their work is for them to respect the vastly bigger amount of work
> done by all other DDs collectively.

I think that the whole project should keep that in mind, not just the
Release Team, and I feel there are many people who don't care enough
about releases and thus do not help out.

I agree that communicating more often could help, but it would also be
necessary to agree on some common goals for the project, so that we
really are working all together as a community instead of just doing
some solo work. That's one of the things I plan to do as DPL:
establish (by talking with the affected teams) some common goals to
work on, and communicate them project wide so that we are all working
together towards that.

> Ideally the Release Manager should
> spend more time on communicating with the rest of the project than on
> handling transitions.

I agree with this (and many of the removed-due-to-being-aggressive
quotes).  However, the lack of man power means that the Release
Managers end up in charge of transitions and lack the time to do the
real communication and coordination.

The role of the DPL is to help developers do their work as good as
possible.  In this case, the only thing that can be done is try to
inspire more people to help out with the release team, but this is not
an easy task, since working on transitions requires extra knowledge
that many DDs don't have, and the release team members don't
necessarily have the time to train them.

We currently and very sadly don't have a Release Manager.  Please let
me suggest that, when a Release Manager is appointed, you should
direct your suggestions about management to them, focusing on what
could be done better, without the need to attack whatever was done
wrong in the past.

-- 
Besos,
Marga


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/e8bbf0361003150916o58d9f400x88b4dbe793a7a...@mail.gmail.com

Re: Question for all candidates: Release process

2010-03-15 Thread Frans Pop 
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

2010-03-15 Thread Margarita Manterola 
On Mon, Mar 15, 2010 at 4:09 AM, Lucas Nussbaum
 wrote:

> During the last debconf, the freeze of squeeze was first announced to
> take place in December, then this decision was cancelled, and now we are
> in March.
> - How do you analyze what happened during last summer? What went wrong?

What went wrong: a decision was taken without consulting the affected teams.

This is a situation that has happened over and over again in Debian.
The Debian community does not take it well when they are informed of a
decision already taken without having a say on it. We should learn
from this to never make this mistake again: always keep involved
participants in the loop and consult with other people before
announcing something as a taken decision.

What went right: after the many messages stating that the December
freeze was NOT a good idea, specially after Mark Shuttleworth
clarified what he meant by "freeze" (stating which versions to include
in the release), the Release Team sent a mail saying that freezing in
December was not a good idea and that the freeze would most probably
happen on early 2010.

> - What is your opinion on the motivations for the proposal to freeze in
>  December? Specifically, in the future, should we try to coordinate our
>  release process with Ubuntu's?

I think it's generally a good idea, *BUT* I think we should freeze
about the time when Ubuntu releases the LTS, *NOT* 4 or 5 months
before.  Because, as we all know, Ubuntu doesn't really freeze until
really close to the release. So, freezing before that is the same as
not coordinating at all.  This would mean that Ubuntu would release
the LTS in April and Debian would release maybe in July or August. I'm
perfectly ok with that.

I also think that releasing roughly every two years, with a
kernel/X/etc upgrade in the middle (like was done with etchnhalf), is
good. I value stability far more than "bleeding edge", and I know that
releasing more often than that is going to have quite an impact in
stability.  Where I work, most users (about 150) are still using Etch,
because they are used to it and have no real need of anything newer.

All in all, this is my opinion as just a DD.  The release process is
the work of the Release Team, and it's their call in the end.
However, to avoid the turmoil caused last year after the DebConf
keynote / press release, the RT should always keep involved teams in
the loop when setting a release (or freeze) date.

> - So, we are now in March. What is your opinion with the release process
>  so far? When do you see the release happening?

I'm very saddened by Luk's resignation from yesterday, I think it's
mainly the result of having to do too much work by too few people.
This leads to stress and frustration, and those tend to lead to
resignations.  Now we have to give the team some time to re-arrange
themselves and find a way to continue.

I won't make any predictions, since they'd make very little sense in
the current context.  I do plan to help the Release Team releasing
squeeze, in whatever my capacity, and I'm hoping that it'll happen
this year, so that the whole LTS syncing thing can happen.  However,
if in order to have a stable, robust and clean release we ended up
releasing in 2011, I'd still consider it a good trade off, and I'd
still back up the Release Team.

-- 
Besos,
Marga


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/e8bbf0361003150814w52c2ee60h9ab8050311128...@mail.gmail.com

Re: Question for all candidates: Release process

2010-03-15 Thread Margarita Manterola 
On Sun, Mar 14, 2010 at 6:44 PM, Russ Allbery  wrote:

> Releasing is regularly the hardest thing that Debian does, not just
> technically but also socially.  Apart from the standard issues of setting
> deadlines, RC bug counts being high, and similar difficult technical
> issues, the process seems to eat volunteers.  There's usually always at
> least some frustration, anger, and upsetness, and there seems to usually
> be at least one resignation over the course of a release, often in a way
> that hurts other activities in Debian for a time.

I think that most of the frustration comes from the fact that the
release team is lacking manpower.  The job of the release team is very
stressful and very rarely do the RM and RA feel that their work is
appreciated.

> Do you have any ideas how, as DPL, you would (or even could) address this?

I've been thinking about this, due to the recent events, and I'm not
sure I have a solution.  As I've already commented, I'd like to set up
some projects that encourage more external (and internal as well)
contributors both to report and fix more bugs.  However, there's much
more to the release work than fixing RC bugs: managing transitions is
a LOT of work, that requires extra knowledge, and only DDs can do it.

We know from past experiences that throwing money at the problem would
only bring more trouble, so that's out of the picture.

So, the only way I see to help is documenting the work needed and
asking for help.  Maybe if more DDs knew the work needed to get their
own packages into testing, they would be able to help there, and
reduce the pressure on the Release Team.

> I'm personally the most concerned with the social issues.  A delayed
> release can be frustrating but doesn't have that much negative impact, but
> volunteers with enough knowledge of Debian to be able to serve as release
> managers or helpers are rare.  And usually the arguments not only hurt
> their contributions to Debian but usually hurt the contributions to Debian
> of the people on the other side of the argument as well, who are often
> also valuable and difficult-to-replace volunteers.

I agree with all of this, and I'm very much concerned about this
myself.  However, I don't see an easy way to fix this.  My ideas are
on how to make it easier to help out, but people won't necessary want
to help, and I can't think of a way to magically make people want to
help.

-- 
Besos,
Marga


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/e8bbf0361003150642h6d3f431ejb3b1bd852f5b4...@mail.gmail.com

Re: Question for all candidates: Release process

2010-03-15 Thread Lucas Nussbaum 
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

Question for all candidates: Release process

2010-03-14 Thread Russ Allbery 
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?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878w9ushn4@windlord.stanford.edu