Re: 2.3 Proposed Features

[Christian Meyer <chrisime uni de>]

Hi!

On Mon, 3 Feb 2003 20:56:50 -0500
Havoc Pennington wrote:

> The concern is that holding a freeze for much longer than we have in
> the past starts to slow forward progress because CVS is frozen for too
> long.

OK, 6 - 8 months should be ok then.
 
> Some bugs can. Bugs that are "design bugs" or "big hard bugs" ("need
> to rewrite the MIME system") really can't. Also UI bugs can't, you'll
> break docs and i18n. These can only be fixed by moving the release
> cycle forward quickly. That's why we want to release often.

Hmm, so when I'm trying to fix a UI issue (I don't want to paste the URL again
;-) )
it results in breaking docs?
 
> I've heard this argument once already for breaking the 2.2 feature
> freeze, and 2.2 isn't even out yet. And I've gotten it many many times
> in the past.

I see.

> 6 months is fine, 7.5 months is fine, 9 months is IMO too long.  Plus
> the plan needs to leave margin for error; if you definitely want to
> make 7, put 6 in the plan.

Ok, i can really live with that, now that you've explained it :-)

> Waiting for GTK 2.4 potentially delays us 12 months, so it's just
> right out.

..which is really bad.

> There's no benefit to a longer cycle as long as we insist on the
> dogfood rule, as we must and should. If developers can always use CVS
> HEAD as their daily desktop, then it's never more than a standard
> freeze cycle away from release.
> 
> If a change involves breaking dogfoodability, that change simply does
> not go in until it's fixed.

Fixing UI stuff shouldn't bread that rule ;)

> You realize that closing all bugs in bugzilla would take about 5
> years. *If* we didn't add any features in the meantime. And I'm not
> exaggerating when I say 5 years. I'm probably underestimating.

I wasn't talking about fixing all bugs, just about the annoying and
nasty/visible ones.

> The goal is never bug-free. The goal is to be better than what people
> are using now. i.e. the metric is whether you are improving people's
> experience, and by how much, how quickly.
> 
> If you have something that is significantly better, not releasing it
> is wrong. One criterion for significantly better is no showstopper
> bugs, such as major crashes or regressions. But "zero bugs" certainly
> isn't a criterion.

You're definitely right, but life should be easier for developers, too. Thus,
the current toolbar "problem" should also be fixed.

Greetings,
Christian