Re: 2.3 Proposed Features

[Havoc Pennington <hp redhat com>]

On Mon, Feb 03, 2003 at 09:20:52PM +0100, Christian Meyer wrote: 
> Ok, that's fine. But as I explained in a previous mail, a 6 months
> release-cycle is too short. We don't have enough developers to do that and IMO
> it's safer to have a 8 or 9 months release-cycle where we can fix more critical
> bugs.

That's not how it works. 8 or 9 months doesn't mean you fix more bugs,
it means you have a longer devel cycle then the same length
bugfix/freeze cycle. So you introduce more bugs, then fix the same
amount.

You can't lengthen the bugfix/freeze part, it stifles too much
innovation and other work.

Longer cycles cause countless problems:

 - takes longer for users to get bugfixes

 - people start using the "but the devel branch won't be released
   forever!" excuse to feature creep the stable branch

 - stable branch becomes unstable as a result

 - people aren't working on the unstable branch as a result

This *has* happened in the past, we learned the hard way.

The key point here is: developers must be actively working on the
closest possible thing to the GNOME that a significant number of users
are actively using. This is why we have the "always dogfoodable from
CVS" rule among others. If you break this rule, you spiral into
disaster very quickly.

> I'll try to fix some bugs in nautilus when university is over; right now I
> don't have much time. I think there're several other people which have the same
> problem.

Well that's fine, you can still fix bugs for GNOME 2.6, or in the
stable branch of 2.2 or 2.4. There's no reason bugs can only be fixed
on HEAD.
 
> And for GNOME2.4.1 you want to make it depend upon gtk2.4? *yikes*

No, GNOME 2.6 would depend on GTK 2.4.

> Why should there be so many problems with gtk2.4. Maybe I just don't know about
> the real problems, but gtk2.2 wasn't that problematically.

GTK 2.2 was well underway when GNOME 2.2 started, GTK 2.4 isn't, and
GTK 2.4 has more new APIs.

> >  - on the other hand, we're going to want the stuff landing in gtk+
> >    module in CVS as soon as it's relatively in shape. Which is kind of
> >    in conflict with having the stuff living where it's testable
> >    by apps that can't rely on GTK+ unstable branch.
> 
> That's when we'll have a 6 months release-cycle ;-)
> The software can't be extensively tested, but it's very important to
> do that.

You can perfectly well test software with a 6-month cycle, you just
have to punt features as required - that's the whole point. We're
punting the GTK 2.4 feature here. Because GNOME releases are
time-based, not feature-based. The question isn't what time allows us
to get in GTK 2.4, it's can GTK 2.4 be done in the time available.

The reason we're time-based is because frequent releases - ensuring
under-development code matches what users are using - are the
foundation that makes open source development work.

Havoc