Re: 2.3 Proposed Features

[Havoc Pennington <hp redhat com>]

On Tue, Feb 04, 2003 at 01:45:55AM +0100, Christian Meyer wrote: 
> Yep, you're right there. But wouldn't it be possible to like freeze the
> introduction of new features earlier to make sure, that bugs can be fixed for
> some more weeks?

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.

> > Longer cycles cause countless problems:
> > 
> >  - takes longer for users to get bugfixes
> 
> bugs can be fixed in the current stable release, can't they?

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.

> >  - people start using the "but the devel branch won't be released
> >    forever!" excuse to feature creep the stable branch
> 
> uhm, I'm not sure about it...

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.

> >  - stable branch becomes unstable as a result
> > 
> >  - people aren't working on the unstable branch as a result
> 
> I'm quite sceptical about your opinion. Gnome 2.0 -> Gnome 2.2 was approx. 7.5
> months and it didn't hurt us at all. I think it won't hurt if Gnome 2.4 will be
> released in early September,

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.

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

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.

> Fine, I don't have any problems about punting features, but I'm not feeling
> well about punting bugs :-(

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.

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.

Havoc