Re: Questions to all candidates: Release importance, release blockers, release quality

[Loïc Minier]

On Mon, Mar 05, 2007, Clown Adams wrote:
> Are you referring to Frans or AJ when you say that?

 Don't be jealous.

-- 
Loïc Minier <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Clint Adams]

On Mon, Mar 05, 2007 at 06:09:24PM -0800, Steve Langasek wrote:
> There's a difference between criticizing someone's work, and being an
> insufferable prick.

Are you referring to Frans or AJ when you say that?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Steve Langasek]

On Mon, Mar 05, 2007 at 01:41:22PM +0100, Josselin Mouette wrote:
> Le lundi 05 mars 2007 à 13:58 +0200, Kalle Kivimaa a écrit :
> > This attitude is the very single one that I absolutely hate in
> > volunteer organizations. Why should you get mocked for doing things
> > you like with no compensation? What moral right do the mockers have?

> I'm getting pissed off by this attitude of many free software
> developers, who think that no one has the right to criticise their work,
> because they are volunteers.

There's a difference between criticizing someone's work, and being an
insufferable prick.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Josselin Mouette]

Le lundi 05 mars 2007 à 15:05 +0200, Kalle Kivimaa a écrit :
> Well, if *I* get compensated enough, I'm willing to be mocked :) So
> yes, I find it somewhat more acceptable.
> 
> As a semi-RL example, I've been thinking about a game fee for sports
> officials: travel costs plus 20 euros per each insult from a player,
> coach or a spectator. I would get rich pretty quick...

How much would you charge for being insulted on this mailing list?

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: Questions to all candidates: Release importance, release blockers, release quality

[Sam Hocevar]

On Mon, Mar 05, 2007, Kalle Kivimaa wrote:
> Josselin Mouette <[EMAIL PROTECTED]> writes:
> > When you are in a visible position in a group, you are also in the
> > position to be mocked, and it's something people should get used to.
> 
> This attitude is the very single one that I absolutely hate in
> volunteer organizations. Why should you get mocked for doing things
> you like with no compensation? What moral right do the mockers have?

   Does your "no compensation" clarification mean that it is not as
unacceptable to mock people for doing things they like if they do get
compensated?

Curious,
-- 
Sam.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Josselin Mouette]

Le lundi 05 mars 2007 à 01:16 -0800, Steve Langasek a écrit :
> On Sun, Mar 04, 2007 at 10:25:24AM +0100, Josselin Mouette wrote:
> > I hope you realize Sam's blog posts were one of the reasons why I was
> > able to keep up the time I spend on Debian. It is just so much better
> > when the work you are doing has a bit of fun.
> 
> So you only find motivation in things that demotivate Andi?

When you are in a visible position in a group, you are also in the
position to be mocked, and it's something people should get used to. As
long as it is not always about the same people, I find it something
sane, which brings fun to the project - something we are terribly
missing currently.

Sure, it is less fun when you are the one mocked, but you get
compensation next time. And if my work needs criticism, I'd prefer to
see the it done in funny pictures rather than in stupid flamewars like
Greg Folkert's.

> Do we get to vote on which of you two we'd like to be demotivated?

Yes. Everything in Debian should be decided by vote. It is so efficient.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: Questions to all candidates: Release importance, release blockers, release quality

[Kalle Kivimaa]

Josselin Mouette <[EMAIL PROTECTED]> writes:
> When you are in a visible position in a group, you are also in the
> position to be mocked, and it's something people should get used to.

This attitude is the very single one that I absolutely hate in
volunteer organizations. Why should you get mocked for doing things
you like with no compensation? What moral right do the mockers have?

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Kalle Kivimaa]

Josselin Mouette <[EMAIL PROTECTED]> writes:
> If I understand your opinion, Greg Folkert's way of criticising people
> is acceptable, while Sam's is not. Is that correct?

I don't have a ready-made opinion on either Greg or Sam, I haven't
really read that many opinions by either. I took a quick look at
-project and -devel for the last month and I personally would say that
in the Linus/Gnome thread, Greg was at least close to being mocking,
especially in his last post. Sam didn't have any really
confrontational posts on those two lists last month, but I did find
his Etch release stress-o-meter potentially crossing the line.

So, I cannot really give you a blanket statement on either Greg's or
Sam's way of arguing, sorry. I'm not really sure what purpose that
kind of a statement would serve, but if you really want an answer for
me, please give me some detailed examples.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Josselin Mouette]

Le lundi 05 mars 2007 à 13:58 +0200, Kalle Kivimaa a écrit :
> This attitude is the very single one that I absolutely hate in
> volunteer organizations. Why should you get mocked for doing things
> you like with no compensation? What moral right do the mockers have?

I'm getting pissed off by this attitude of many free software
developers, who think that no one has the right to criticise their work,
because they are volunteers.

There is nothing like a moral right to mock people, just like there is
nothing like a moral right not to be mocked.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: Questions to all candidates: Release importance, release blockers, release quality

[Kalle Kivimaa]

Sam Hocevar <[EMAIL PROTECTED]> writes:
>Does your "no compensation" clarification mean that it is not as
> unacceptable to mock people for doing things they like if they do get
> compensated?

Well, if *I* get compensated enough, I'm willing to be mocked :) So
yes, I find it somewhat more acceptable.

As a semi-RL example, I've been thinking about a game fee for sports
officials: travel costs plus 20 euros per each insult from a player,
coach or a spectator. I would get rich pretty quick...

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Kalle Kivimaa]

Josselin Mouette <[EMAIL PROTECTED]> writes:
> I'm getting pissed off by this attitude of many free software
> developers, who think that no one has the right to criticise their work,
> because they are volunteers.

Criticise, yes. Mock, no.

I'll define the terms, just to be clear:

Criticise: To discuss the merits or demerits of a thing or person;
esp., to find fault. [Webster]

Mock: To make sport in contempt; to speak in a scornful or jeering
manner. [Webster]

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Michael Banck]

On Mon, Mar 05, 2007 at 02:52:32PM +0100, Josselin Mouette wrote:
> Le lundi 05 mars 2007 à 14:52 +0200, Kalle Kivimaa a écrit :
> > Criticise, yes. Mock, no.
> 
> If I understand your opinion, Greg Folkert's way of criticising people
> is acceptable, while Sam's is not. Is that correct?

Greg isn't a DD, just a user who vented on the wrong list, AFAIK.  Plus,
I was sort of on the receiving end of his mockery, so I'm biased, but I
didn't like it at all either.

(I didn't like the mocking of other (some of them quite well-known) DDs
in that thread either, but those were more mocking Gnome anymously than
the Debian Gnome-team or the Gnome upstream developers in particular)


Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Josselin Mouette]

Le lundi 05 mars 2007 à 14:52 +0200, Kalle Kivimaa a écrit :
> Criticise, yes. Mock, no.

If I understand your opinion, Greg Folkert's way of criticising people
is acceptable, while Sam's is not. Is that correct?

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: Questions to all candidates: Release importance, release blockers, release quality

[Steve Langasek]

On Sun, Mar 04, 2007 at 10:25:24AM +0100, Josselin Mouette wrote:
> Le dimanche 04 mars 2007 à 10:21 +0100, Andreas Barth a écrit :
> > I hope you realize that your blog posts were one of the reasons why I
> > reduced the time I spend on the release dramatically. It is just
> > frustrating if people try to destroy the work you are doing.

> I hope you realize Sam's blog posts were one of the reasons why I was
> able to keep up the time I spend on Debian. It is just so much better
> when the work you are doing has a bit of fun.

So you only find motivation in things that demotivate Andi?

Do we get to vote on which of you two we'd like to be demotivated?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[MJ Ray]

Andreas Schuldei <[EMAIL PROTECTED]>
> julien, what is [...]

Please stop cluttering the list with personal attacks on non-candidates
(and preferably don't character-asassinate candidates either).
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Steve McIntyre]

[ First of all, apologies for the delayed response; I'm catching up
  after several days of FOSDEM-plague :-( ]

Hi Marc,

On Mon, Feb 26, 2007 at 12:16:21PM +0100, Marc 'HE' Brockschmidt wrote:
>Hi,
>
>I would be happy to hear answers from all candidates to these questions,
>but I expect that they are at least partially answered by the
>platforms. Please simply point to them if you included an answer there,
>even if they are not online yet. 
>
>So, to the questions:
>
>* How important are regular releases for the project?

In my opinion, very important. For all that we have large numbers of
developers and users following unstable or testing, in my experience
we have a very large userbase depending on our stable releases. From
talking to lots of Debian users, a regular release is important to
them. Some have coped with our releases taking longer and longer in
the recent past because they love our stability, but more
predictability in release timings would be wonderful.

>* How important are regular stable point releases for the project?

Also very important; they allow stable users to keep up-to-date with
minimal pain. I'd like us to be more regular with the point releases;
every 2 or 3 months would be ideal.

I'm also very much hoping we can get something new working for etch
point releases: installer updates with newer kernels etc. That would
help solve one of the few issues with our longer release intervals,
which is that new hardware is released which our kernels don't
support.

>* Should we fix up dak to allow point-releases for old-stable?

I'm not convinced that it would be very useful, but I certainly
wouldn't oppose such work. Do you think it should be done?

>* Could you list the issues that you think delayed the release of etch?
>  Do you think that we need to restructure the release process for lenny
>  to avoid these? If yes, how?

As I see it, the issues that have delayed etch have mainly been
kernel-related. We've been waiting quite a long time for a releasable
kernel to make it into the archive, and that has been blocking d-i RC2
(and hence the release itself. We've had a lot of RC bugs open, but I
don't actually see them as a major release blocker. It's easy enough
to remove most packages with RC bugs when we're ready, and otherwise
expecting to hit 0 RC bugs for release is never a realistic goal.

I don't think we need to restructure the release process necessarily,
but maybe we do need to get more people involved and caring about the
process/date earlier on. I have personally been *very* impressed with
the etch release team, and I wish more people could be as
dedicated.

The big difference this time (imho) is that once sarge released we did
*not* just let things go for a while, hoping to clean up later. This
time, migrations to testing have mostly been very well managed, with
bigger updates closely monitored and controlled throughout the
cycle. That has made a huge difference, and I applaud the effort
involved on all sides.

>* Do you think that a release of high quality is more important than a
>  timely release? [ie: Should we switch from "when it's ready" to "when
>  we said we would release"]

A compromise would be nice, and should certainly be possible. If we
can agree upon and set a *reasonable* expected date, most of our
issues should be predictable enough to allow us to freeze appropriate
versions of all the larger package sets (Gnome, KDE, kernel, X, etc.)
with enough time to make that date *and* still meet our expected high
quality standards.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"You can't barbecue lettuce!" -- Ellie Crane


signature.asc
Description: Digital signature

Re: Questions to all candidates: Release importance, release blockers, release quality

[Aigars Mahinovs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> So, to the questions:
> 
> * How important are regular releases for the project?

Less important then the quality of said releases and the overall
importance of the Debian project in the free software movement.

> * How important are regular stable point releases for the project?

They are useful for the users with little to no connectivity and need to
be done from time to time.

> * Should we fix up dak to allow point-releases for old-stable?

Not if it requires significant work. I see little point in this, but if
someone sees more reason to do this and has the coding ability, then it
cold be done.

> * Could you list the issues that you think delayed the release of etch?
>   Do you think that we need to restructure the release process for lenny
>   to avoid these? If yes, how?

No, I do not think it is required to speed up our releases more.

> * Do you think that a release of high quality is more important than a
>   timely release? [ie: Should we switch from "when it's ready" to "when
>   we said we would release"]

No, IMHO "when it's ready" is more then appropriate with a guide of one
release every 18-24 months.

- --
Best regards,
Aigars Mahinovsmailto:[EMAIL PROTECTED]
 #--#
 | .''`. Debian GNU/Linux  LAKA |
 |: :' :  http://www.debian.org  &  http://www.laka.lv  |
 |`. `' |
 |  `-  |
 #--#
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF6t73MzCiFWcgm94RAtMlAJ0ZRU/neBs0oXO+W7x5h2h6lUVWEgCghwAQ
GOEVr2pC9V+46ccRN0FlyFQ=
=dhEZ
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Julien BLACHE]

Andreas Schuldei <[EMAIL PROTECTED]> wrote:

> julien, what is your agenda here? you come across as distracting
> and trolling. you contributed nothing worthwhile so far. please
> stop it and dont generate avoidable traffic during election time
> (which is busy enough as it is).

Contrary to others here, I have no agenda to push.

Thanks for asking.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Andreas Schuldei]

* Julien BLACHE ([EMAIL PROTECTED]) [070304 13:17]:
> Or just some people lacking a sense of humor.
> 
> It's so easy to dismiss anything you don't like as being either
> trolling or a cheap ad hominem attack instead of, you know, just
> thinking about it for a minute, asking yourself if, by any chance,
> there wouldn't be a little something behind it.

julien, what is your agenda here? you come across as distracting
and trolling. you contributed nothing worthwhile so far. please
stop it and dont generate avoidable traffic during election time
(which is busy enough as it is).


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Julien BLACHE]

Mike Hommey <[EMAIL PROTECTED]> wrote:

>> And, like Joss, sam's posts brought some fun back into Debian at a
>> time where I really needed it to continue working on Debian.
>
> I think there might be a cultural issue...

Or just some people lacking a sense of humor.

It's so easy to dismiss anything you don't like as being either
trolling or a cheap ad hominem attack instead of, you know, just
thinking about it for a minute, asking yourself if, by any chance,
there wouldn't be a little something behind it.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Mike Hommey]

On Sun, Mar 04, 2007 at 11:46:53AM +0100, Julien BLACHE <[EMAIL PROTECTED]> 
wrote:
> Andreas Barth <[EMAIL PROTECTED]> wrote:
> 
> > I hope you realize that your blog posts were one of the reasons why I
> > reduced the time I spend on the release dramatically. It is just
> > frustrating if people try to destroy the work you are doing.
> 
> Nothing too dramatic, really.
> 
> And, like Joss, sam's posts brought some fun back into Debian at a
> time where I really needed it to continue working on Debian.

I think there might be a cultural issue...

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Julien BLACHE]

Andreas Barth <[EMAIL PROTECTED]> wrote:

> I hope you realize that your blog posts were one of the reasons why I
> reduced the time I spend on the release dramatically. It is just
> frustrating if people try to destroy the work you are doing.

Nothing too dramatic, really.

And, like Joss, sam's posts brought some fun back into Debian at a
time where I really needed it to continue working on Debian.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Josselin Mouette]

Le dimanche 04 mars 2007 à 10:21 +0100, Andreas Barth a écrit :
> I hope you realize that your blog posts were one of the reasons why I
> reduced the time I spend on the release dramatically. It is just
> frustrating if people try to destroy the work you are doing.

I hope you realize Sam's blog posts were one of the reasons why I was
able to keep up the time I spend on Debian. It is just so much better
when the work you are doing has a bit of fun.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Questions to all candidates: Release importance, release blockers, release quality

[Andreas Barth]

* Sam Hocevar ([EMAIL PROTECTED]) [070303 14:56]:
> On Fri, Mar 02, 2007, Steve Langasek wrote:
> 
> > To state it plainly: the blocker for the etch release for the past 2 months
> > or so has been the kernel.  This was known, and it was stated.
> > 
> > I don't remember seeing anyone from outside the kernel team step forward to
> > tackle any of the kernel's RC bugs.  This is pretty understandable -- we
> > already have a large kernel team, and the package is not exactly readily
> > NMUable, so trying to focus the whole project's attention on the kernel
> > sounds like a classic mythical-man-month recipe for disaster, in addition to
> > being a pretty huge time investment for any outside developer because of the
> > kernel package's high learning curve.  So what do you think should have been
> > done differently in terms of release management that would have helped keep
> > the release target?
> 
>Has going back to a 2.6.17 kernel been considered? There were
> probably reasons to accept 2.6.18 only four days before base was frozen,
> but that seems all the more questionable now that the new release itself
> didn't seem to fix any bugs, yet introduced new ones (such as #410497).

Unfortunatly, 2.6.17 contains a whole bunch of other RC bugs that are
fixed with 2.6.18. So, it has been considered, but the cure would be
worse than the desease.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Andreas Barth]

* Sam Hocevar ([EMAIL PROTECTED]) [070302 03:36]:
>I know I hurt a few people with my blog entries (though I should
> mention I also got much positive feedback from people who were happy
> to have fun in an otherwise frustrating atmosphere) and I am sorry
> about that. It was my way not to leave the project during the dunc-tank
> controversy (for about a week I considered resigning).

I hope you realize that your blog posts were one of the reasons why I
reduced the time I spend on the release dramatically. It is just
frustrating if people try to destroy the work you are doing.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Steve Langasek]

On Sat, Mar 03, 2007 at 02:33:17PM +0100, Sam Hocevar wrote:
>Has going back to a 2.6.17 kernel been considered?

No.

> There were probably reasons to accept 2.6.18 only four days before base
> was frozen,

Yes, IIRC it was the assessment of the kernel team that 2.6.17 would not be
supportable over the lifetime of etch.

> but that seems all the more questionable now that the new
> release itself didn't seem to fix any bugs, yet introduced new ones (such
> as #410497).

399113 is an RC bug that was fixed upstream in later 2.6.18.x patchlevels.
(The bug was only reported after 2.6.18 was uploaded, but I don't see any
positive evidence that the bug was new in 2.6.18.)

389232 was filed against 2.6.17 and was fixed upstream in 2.6.18.

The upstream diff may have been relevant to fixing bugs #394392 and 406055
via backports.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[David Nusinow]

This should probably go on -devel or -project, so feel free to move the
thread.

On Fri, Mar 02, 2007 at 02:12:46AM -0800, Steve Langasek wrote:
> To state it plainly: the blocker for the etch release for the past 2 months
> or so has been the kernel.  This was known, and it was stated.
> 
> I don't remember seeing anyone from outside the kernel team step forward to
> tackle any of the kernel's RC bugs.  This is pretty understandable -- we
> already have a large kernel team, and the package is not exactly readily
> NMUable, so trying to focus the whole project's attention on the kernel
> sounds like a classic mythical-man-month recipe for disaster, in addition to
> being a pretty huge time investment for any outside developer because of the
> kernel package's high learning curve.  So what do you think should have been
> done differently in terms of release management that would have helped keep
> the release target?

One thing that's disturbed me is that I haven't seen any sort of statements
from the kernel team as to what's going on. I've heard this from the d-i
team and the release team, but no one from the kernel team has really said
anything as to what went wrong and what they're planning to do to correct
it in the future. All the other large package teams have pretty much
avoided being The Big Release Problem, and I'd personally like to know what
went wrong with the kernel so it can be avoided next time.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Sam Hocevar]

On Fri, Mar 02, 2007, Steve Langasek wrote:

> To state it plainly: the blocker for the etch release for the past 2 months
> or so has been the kernel.  This was known, and it was stated.
> 
> I don't remember seeing anyone from outside the kernel team step forward to
> tackle any of the kernel's RC bugs.  This is pretty understandable -- we
> already have a large kernel team, and the package is not exactly readily
> NMUable, so trying to focus the whole project's attention on the kernel
> sounds like a classic mythical-man-month recipe for disaster, in addition to
> being a pretty huge time investment for any outside developer because of the
> kernel package's high learning curve.  So what do you think should have been
> done differently in terms of release management that would have helped keep
> the release target?

   Has going back to a 2.6.17 kernel been considered? There were
probably reasons to accept 2.6.18 only four days before base was frozen,
but that seems all the more questionable now that the new release itself
didn't seem to fix any bugs, yet introduced new ones (such as #410497).

   At least now we know the kernel may have to be frozen sooner.

-- 
Sam.


signature.asc
Description: Digital signature

Re: Questions to all candidates: Release importance, release blockers, release quality

[Steve Langasek]

On Fri, Mar 02, 2007 at 03:36:10AM +0100, Sam Hocevar wrote:
> > Only after the freeze is it possible to do certain kinds of systematic QA,
> > such as checking for build failures within testing.  Have you taken that
> > into account when deeming that a decline of 10-20 bugs over two months
> > indicates too early of a freeze?  Have you factored in the introduction of
> > new RC bugs into testing without detection, prior to the freeze?

>I was aware of all these parameters, but their potential impact on
> the RC bug evolution was all but clear. Again, I would have loved a
> graph of newly found bugs, downgraded ones, bugs fixed by a transition
> to testing, etc. to know the trend for all variables. And since our
> target was 0 RC bugs /in Etch/ I was under the impression that we should
> focus on the RC bug count /in Etch/, which was the main reason why I
> thought freezing at 116 bugs in Etch while it was planned to do it at 80
> was a bit too early.

FWIW, the determination to freeze when we did was made partly in response to
the perception that we had reached the break-even point, where the rate at
which new RC bugs were being introduced into testing due to the lack of
freeze was comparable to the rate at which RC bugfixes were being uploaded.

As has been discussed, we don't have much hard data on this (even analysis
of bug openings and closures wouldn't give us this directly since we would
have to know which bugs are new and which are just newly reported), so all I
can offer is the result of our eyeballing at the time.

>That said, a buffer does not mean we should no longer care about
> the schedule (like we more or less did) if the deadline is missed. The
> workplan should be updated to make up for the delay, priorities should
> be shifted and goals reconsidered. Unless of course we no longer care
> about the release date.

At that point, there was insufficient data to give a reasonable estimate of
the time it would take to get a releasable kernel sorted out.  Having missed
the original target, we weren't inclined to post new release schedules that
we had a low probability of being able to meet.

> > > By dealing with RC bugs by popularity contest instead of date or bug
> > > number, we can reach a higher quality faster.

> > Judging by the number of people who stepped forward to help with the
> > release-critical bugs on the kernel, I guess the kernel isn't very popular
> > with developers.  Is that the popularity contest you mean?

>No, by popularity contest I mean popcon.d.o: focus on bugs in
> packages that affect the most people first. Or did I misunderstand your
> objection?

To state it plainly: the blocker for the etch release for the past 2 months
or so has been the kernel.  This was known, and it was stated.

I don't remember seeing anyone from outside the kernel team step forward to
tackle any of the kernel's RC bugs.  This is pretty understandable -- we
already have a large kernel team, and the package is not exactly readily
NMUable, so trying to focus the whole project's attention on the kernel
sounds like a classic mythical-man-month recipe for disaster, in addition to
being a pretty huge time investment for any outside developer because of the
kernel package's high learning curve.  So what do you think should have been
done differently in terms of release management that would have helped keep
the release target?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Sam Hocevar]

On Tue, Feb 27, 2007, Steve Langasek wrote:

> >   * we announced a bogus release date. I know not everyone agrees on
> >   who is responsible for that announcement,
> 
> Who do you believe is responsible for that announcement?

   The story as I understand it is that the press team slightly changed
the release team's "12/4 confirmed as a realistic date" estimation to
"12/4 confirmed as a release date", and apparently few efforts were made
to take it back.

> Only after the freeze is it possible to do certain kinds of systematic QA,
> such as checking for build failures within testing.  Have you taken that
> into account when deeming that a decline of 10-20 bugs over two months
> indicates too early of a freeze?  Have you factored in the introduction of
> new RC bugs into testing without detection, prior to the freeze?

   I was aware of all these parameters, but their potential impact on
the RC bug evolution was all but clear. Again, I would have loved a
graph of newly found bugs, downgraded ones, bugs fixed by a transition
to testing, etc. to know the trend for all variables. And since our
target was 0 RC bugs /in Etch/ I was under the impression that we should
focus on the RC bug count /in Etch/, which was the main reason why I
thought freezing at 116 bugs in Etch while it was planned to do it at 80
was a bit too early.

> >I do think a release of high quality is more important than a timely
> > release. However, I also think it should be possible to stick to a given
> > date (with the usual two-month buffer, of course).
> 
> If you think there's a "usual two-month buffer" that applies to release date
> targets, why, before we'd even reached the original target release date,
> were you publicly mocking the release team's efforts in your blog?

   My first "stress-o-meter" blog post was only four days before the
target release date, but it was also two weeks after you announced the
installer release process was three months behind schedule. And a quick
look at sarge's RC bug graph made me foresee a 3- to 5-month delay.

   That said, a buffer does not mean we should no longer care about
the schedule (like we more or less did) if the deadline is missed. The
workplan should be updated to make up for the delay, priorities should
be shifted and goals reconsidered. Unless of course we no longer care
about the release date.

> I appreciate your support as a maintainer in dealing with release-critical
> bugs that affected your packages.  But why should anyone who cares about
> Debian's stable releases vote for you if that's the sort of support you're
> going to show for the release team as a public figure?

   I know I hurt a few people with my blog entries (though I should
mention I also got much positive feedback from people who were happy
to have fun in an otherwise frustrating atmosphere) and I am sorry
about that. It was my way not to leave the project during the dunc-tank
controversy (for about a week I considered resigning).

   However, my platform says I'm serious, and I am not going to mock the
release team or any of our teams as a project representative.

> > By dealing with RC bugs by popularity contest instead of date or bug
> > number, we can reach a higher quality faster.
> 
> Judging by the number of people who stepped forward to help with the
> release-critical bugs on the kernel, I guess the kernel isn't very popular
> with developers.  Is that the popularity contest you mean?

   No, by popularity contest I mean popcon.d.o: focus on bugs in
packages that affect the most people first. Or did I misunderstand your
objection?

   I hope I don't look like I dodged any questions. Let me know if I
have been inaccurate.

Regards,
-- 
Sam.


signature.asc
Description: Digital signature

Re: Questions to all candidates: Release importance, release blockers, release quality

[Sam Hocevar]

On Wed, Feb 28, 2007, Frank Küster wrote:

> > I appreciate your support as a maintainer in dealing with release-critical
> > bugs that affected your packages.  But why should anyone who cares about
> > Debian's stable releases vote for you if that's the sort of support you're
> > going to show for the release team as a public figure?
> 
> Hm, which blog entry are you speaking of?  Currently, the oldest one I
> find on http://sam.zoy.org/blog/ is from December 11th.

   My old blog entries do not automatically appear. You may want to try
http://sam.zoy.org/blog/?count=20 to see the entries Steve is referring
to.

Regards,
-- 
Sam.


signature.asc
Description: Digital signature

Re: Questions to all candidates: Release importance, release blockers, release quality

[Frank Küster]

Steve Langasek <[EMAIL PROTECTED]> wrote:

[to Sam Hovecar]

> If you think there's a "usual two-month buffer" that applies to release date
> targets, why, before we'd even reached the original target release date,
> were you publicly mocking the release team's efforts in your blog?
>
> I appreciate your support as a maintainer in dealing with release-critical
> bugs that affected your packages.  But why should anyone who cares about
> Debian's stable releases vote for you if that's the sort of support you're
> going to show for the release team as a public figure?

Hm, which blog entry are you speaking of?  Currently, the oldest one I
find on http://sam.zoy.org/blog/ is from December 11th.

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Questions to all candidates: Release importance, release blockers, release quality

[Steve Langasek]

On Tue, Feb 27, 2007 at 07:25:36PM +0100, Sam Hocevar wrote:
> > * Could you list the issues that you think delayed the release of etch?
> >   Do you think that we need to restructure the release process for lenny
> >   to avoid these? If yes, how?

>From an email I sent to madduck for a recent talk of his, on February
> 12th:

>   * we announced a bogus release date. I know not everyone agrees on
>   who is responsible for that announcement,

Who do you believe is responsible for that announcement?

>   * we froze too early (at 116 RC bugs in etch), ignoring the fact that
>   once we freeze, package transitions mean more work for the developers
>   and more work for the release maintainers. Two months after the
>   freeze, we [were] down by 10 or 20 RC bugs, not much more. [Today it's
>   getting a lot better.]

Only after the freeze is it possible to do certain kinds of systematic QA,
such as checking for build failures within testing.  Have you taken that
into account when deeming that a decline of 10-20 bugs over two months
indicates too early of a freeze?  Have you factored in the introduction of
new RC bugs into testing without detection, prior to the freeze?

> > * Do you think that a release of high quality is more important than a
> >   timely release? [ie: Should we switch from "when it's ready" to "when
> >   we said we would release"]

>I do think a release of high quality is more important than a timely
> release. However, I also think it should be possible to stick to a given
> date (with the usual two-month buffer, of course).

If you think there's a "usual two-month buffer" that applies to release date
targets, why, before we'd even reached the original target release date,
were you publicly mocking the release team's efforts in your blog?

I appreciate your support as a maintainer in dealing with release-critical
bugs that affected your packages.  But why should anyone who cares about
Debian's stable releases vote for you if that's the sort of support you're
going to show for the release team as a public figure?

> By dealing with RC bugs by popularity contest instead of date or bug
> number, we can reach a higher quality faster.

Judging by the number of people who stepped forward to help with the
release-critical bugs on the kernel, I guess the kernel isn't very popular
with developers.  Is that the popularity contest you mean?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Sam Hocevar]

On Mon, Feb 26, 2007, Marc 'HE' Brockschmidt wrote:

> * How important are regular releases for the project?

   Very. Regular releases make our users faithful, prevent them from
getting bored and trying something else. They also give credibility when
approaching hardware vendors (they don't want to support old versions of
Linux or other components) and even proprietary software vendors from
which we would like certifications.

   I think our long release process is the main cause for our declining
"marketshare".

> * How important are regular stable point releases for the project?

   Very important, too (though if workforce were to become an issue,
I'd still rather have regular releases). But if we have more frequent
releases, the work needed for stable point releases will mathematically
lessen.

> * Should we fix up dak to allow point-releases for old-stable?

   Yes. Again, if we are to have regular releases, I hope it will mean
more frequent releases (eg. 12 months or even fewer) in which case
old-stable will not be /that/ old, and will require attention.

> * Could you list the issues that you think delayed the release of etch?
>   Do you think that we need to restructure the release process for lenny
>   to avoid these? If yes, how?

   From an email I sent to madduck for a recent talk of his, on February
12th:

  * we announced a bogus release date. I know not everyone agrees on
  who is responsible for that announcement, but if we end up saying etch
  is late, it's obviously late relative to some date. I know it takes
  pride to take back an announcement, but my feeling is that admitting
  earlier on that the initial claim was unrealistic would have caused
  less PR damage.

  * we ignored both the average evolution of RC bugs from previous
  releases and the fact that on every release we're going twice as
  slowly as our expectations. The RC bug count monitoring was quite
  cloudy, with at least three different sources of information and
  no precise measurement (for instance aba, in one of his dunc-tank
  reports, mentioned that there was no tool to monitor how many bugs
  were opened and how many were closed, only the delta was plotted;
  I would have expected such a tool to appear during the dunc-tank
  process but it hasn't).

  * although I am unable to quantify it, the dunc-tank controversy
  certainly helped delay etch, whoever was responsible for it. For
  instance, Joss orphaned libpng out of frustration and it was adopted
  by Anibal who screwed up a few uploads because he was unfamiliar with
  the package; certainly Anibal is partly responsible for the RC bugs
  that ensued, yet others will claim that Joss is responsible because he
  abandoned libpng and/or was stubborn about dunc-tank, and some others
  will blame dunc-tank for causing Joss to reduce his involvement. This
  is just an isolated example that is not meant to illustrate all the
  possible consequences but I think it clearly shows how the responsi-
  bilities are shared.

  * we froze too early (at 116 RC bugs in etch), ignoring the fact that
  once we freeze, package transitions mean more work for the developers
  and more work for the release maintainers. Two months after the
  freeze, we [were] down by 10 or 20 RC bugs, not much more. [Today it's
  getting a lot better.]

  * [...] <- [here was something that TTBOMK was only discussed on
  debian-private and whose decision to disclose is not mine, you can
  contact me by email if you feel it's important.]

  * maybe we miscalculated our priorities: the installer and the kernel
  were far worse blockers than the RC bugs on hardly used packages, yet
  the release timeline sticked to the RC bug count. Now I haven't
  followed what these teams were doing and I don't mean to imply that
  the RMs weren't working on these issues, but I have seen little
  communication from them about the remaining issues in d-i and the
  kernel.

   And yes, I think it is necessary to restructure the release process.
I will comment about it in another email or this one will become quite
unreadable.

> * Do you think that a release of high quality is more important than a
>   timely release? [ie: Should we switch from "when it's ready" to "when
>   we said we would release"]

   I do think a release of high quality is more important than a timely
release. However, I also think it should be possible to stick to a given
date (with the usual two-month buffer, of course). For that we need to
rethink what "quality" means. Quality is not a mere RC bug count, there
are other factors even when only looking at bugs. We have never shipped
a zero-bug release, and we will never, some normal bugs are hurting more
than RC bugs, and there are bugs that no developer or user cares about.
By dealing with RC bugs by popularity contest instead of date or bug
number, we can reach a higher quality faster.

Regards,
-- 
Sam.


signature.asc
Description: Digital signature

Re: Questions to all candidates: Release importance, release blockers, release quality

[Anthony Towns]

On Mon, Feb 26, 2007 at 12:16:21PM +0100, Marc 'HE' Brockschmidt wrote:
> So, to the questions:
> * How important are regular releases for the project?

Predictable stable releases are very important.

> * How important are regular stable point releases for the project?

Having stable releases be supported for a long time is important. Stable
point releases are helpful at that -- in that they make it easier
for people to install systems that are secure as soon as they boot,
and reduce the load on our security mirrors -- but aren't crucial. What
we're achieving, which is every few months, and at least every six months,
is pretty respectable, imo. (Disclaimer: I'm one of the delaying factors
in getting stable releases out, since I've been doing the ftpmaster side
of it over the past year)

> * Should we fix up dak to allow point-releases for old-stable?

Yes -- that will let us do longer term support stable releases, rather
than cutting them off a year after the next stable release.

> * Could you list the issues that you think delayed the release of etch?

Things that weren't ready on time include:

   * freeze (Dec 11th)
   * iceweasel/etc (was ready sometime in january iirc)
   * RC bug count (still high)
   * kernel (ready to hit testing any time now)

I presume the release team have a better idea; I'm certainly
hoping/intending that the Dunc-Tank report will give a more detailed
summary. I'm pretty impressed that, aiui, d-i wasn't one of those things
in any significant way.

>   Do you think that we need to restructure the release process for lenny
>   to avoid these? If yes, how?

That's the release team's call.

> * Do you think that a release of high quality is more important than a
>   timely release? [ie: Should we switch from "when it's ready" to "when
>   we said we would release"]

We should switch from "We don't know when it will be ready" to "It'll
almost certainly be ready by __". That means being able to do a
better job of lots of things -- managing the things that weren't ready
on time for etch better in future, eg.

It doesn't mean changing our standards *at all* though.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Questions to all candidates: Release importance, release blockers, release quality

[Gustavo Franco]

On 2/26/07, Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> wrote:

Hi,

I would be happy to hear answers from all candidates to these questions,
but I expect that they are at least partially answered by the
platforms. Please simply point to them if you included an answer there,
even if they are not online yet.


Hi Marc,

That's good to see some questions coming from you.


So, to the questions:

* How important are regular releases for the project?


They're important, but i'm confident that with some more cooperation
between core teams and others developers, the RM team can do a even
better job. I see regular releases as a result on how well these
blocks work together and how much they work.


* How important are regular stable point releases for the project?


They're critical in a world where we've regular releases and even more
needed in a world we've no regular releases. We've great tools to turn
it easier to follow the stable updates, but our users demand a
reference: The point releases.


* Should we fix up dak to allow point-releases for old-stable?


I don't really think it's critical, in my humble developer and user
POV, but if elected, be sure that i won't disagree if anybody come in
and contribute with the fix. There are different point of views and if
it don't add more load on people that doesn't want to work on
point-releases for old-stable, we will just need volunteers that want
to take the task and actually really do it.


* Could you list the issues that you think delayed the release of etch?
  Do you think that we need to restructure the release process for lenny
  to avoid these? If yes, how?


Basically, lack of communication between some core teams and between
some core teams and others DDs; dunc-* discussions and our release
process itself, that isn't totally wrong, but we can improve IMHO.
How? Please read below.


* Do you think that a release of high quality is more important than a
  timely release? [ie: Should we switch from "when it's ready" to "when
  we said we would release"]


Since we depend a lot on software coming outside Debian in terms of
quality and timely release, i would like to see a goal based release
schedule considering time and some key upstream projects. It will be
better explained in my platform, i hope you like it.

Thanks for your questions, i'll add them and my answers on my campaign page, ok?

regards,
-- stratus
http://stratusandtheswirl.blogspot.com


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Raphael Hertzog]

Hello,

I'm mostly in agreement with what Wouter expressed so I'll simply point
out what's different for me.

On Mon, 26 Feb 2007, Wouter Verhelst wrote:
> On Mon, Feb 26, 2007 at 12:16:21PM +0100, Marc 'HE' Brockschmidt wrote:
> > * How important are regular releases for the project?
> 
> Very. Individual people may be happy with testing or unstable, but large
> corporate users need stable releases in order to be able to use Debian.

Ack.

> > * How important are regular stable point releases for the project?
> 
> They are also important, albeit perhaps not as important as regular
> stable releases. What they provide is the convenience of having security
> updates all in place, and they have especial value for modem users.

Ack but they could become more important if we manage to provide newer kernels
once in the life cycle for example. I know several people plan to do that
for etch and I would like to give them my support.

> > * Should we fix up dak to allow point-releases for old-stable?
> 
> No, I don't think that is very useful. Oldstable is there to allow
> people to transition to the current stable while not losing security
> support. It should not be used for new installations; and since I think
> the main advantage which stable point releases bring is convenience on
> new installations, there is no point in doing point-releases for
> oldstable.

Ack.

> > * Could you list the issues that you think delayed the release of etch?
> >   Do you think that we need to restructure the release process for lenny
> >   to avoid these? If yes, how?
> 
> I did not follow the release process closely enough to properly answer
> this. I hear the main reasons were the lack of a decent enough kernel,
> but do not know any details.

Obviously we also freezed later than expected. The kernel was a big
blocker this year but we also didn't reduce the RC bug count soon enough.

But I have no magic solution except "recruit more volunteers to keep more
packages bug free". And for this we need to be a more welcoming project.

> > * Do you think that a release of high quality is more important than a
> >   timely release? [ie: Should we switch from "when it's ready" to "when
> >   we said we would release"]
> 
> I think both are of equal importance. Debian should not switch to
> time-based releases; however, having a general timeframe as we have done
> for etch certainly is helpful.

Ack.

> It would be interesting if we could find ways to get lenny released at a
> point which is lying closer to the predicted date than will be the case
> for etch. However, we should not do this at all cost.

If we can aim to release every 18 months and effectively release every 22
months, it's ok. Nobody ask us a 100% predictable release. But I discussed
with important users of Debian and when they plan major deployment far
ahead of time then want to know which version is likely to be stable a
given future date. Those kind of projects can be late of a few months, but
they can't be late of a full year.

> That being said, I don't think any of this is the DPL's responsibility;
> the responsibility lies with our Release Managers.

Half-ack. The DPL should be in close contact with the release manager to
help them achieve one of the most important goal of the project.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions to all candidates: Release importance, release blockers, release quality

[Wouter Verhelst]

On Mon, Feb 26, 2007 at 12:16:21PM +0100, Marc 'HE' Brockschmidt wrote:
> * How important are regular releases for the project?

Very. Individual people may be happy with testing or unstable, but large
corporate users need stable releases in order to be able to use Debian.

> * How important are regular stable point releases for the project?

They are also important, albeit perhaps not as important as regular
stable releases. What they provide is the convenience of having security
updates all in place, and they have especial value for modem users.

> * Should we fix up dak to allow point-releases for old-stable?

No, I don't think that is very useful. Oldstable is there to allow
people to transition to the current stable while not losing security
support. It should not be used for new installations; and since I think
the main advantage which stable point releases bring is convenience on
new installations, there is no point in doing point-releases for
oldstable.

> * Could you list the issues that you think delayed the release of etch?
>   Do you think that we need to restructure the release process for lenny
>   to avoid these? If yes, how?

I did not follow the release process closely enough to properly answer
this. I hear the main reasons were the lack of a decent enough kernel,
but do not know any details.

> * Do you think that a release of high quality is more important than a
>   timely release? [ie: Should we switch from "when it's ready" to "when
>   we said we would release"]

I think both are of equal importance. Debian should not switch to
time-based releases; however, having a general timeframe as we have done
for etch certainly is helpful.

It would be interesting if we could find ways to get lenny released at a
point which is lying closer to the predicted date than will be the case
for etch. However, we should not do this at all cost.

That being said, I don't think any of this is the DPL's responsibility;
the responsibility lies with our Release Managers.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Questions to all candidates: Release importance, release blockers, release quality

[Marc 'HE' Brockschmidt]

Hi,

I would be happy to hear answers from all candidates to these questions,
but I expect that they are at least partially answered by the
platforms. Please simply point to them if you included an answer there,
even if they are not online yet. 

So, to the questions:

* How important are regular releases for the project?

* How important are regular stable point releases for the project?

* Should we fix up dak to allow point-releases for old-stable?

* Could you list the issues that you think delayed the release of etch?
  Do you think that we need to restructure the release process for lenny
  to avoid these? If yes, how?

* Do you think that a release of high quality is more important than a
  timely release? [ie: Should we switch from "when it's ready" to "when
  we said we would release"]

Marc


pgpY4Jx45FsYC.pgp
Description: PGP signature