Re: 2.3 Proposed Features

[Christian Meyer <chrisime uni de>]

Hi!

On Mon, 3 Feb 2003 15:35:27 -0500
Havoc Pennington wrote:

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

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?
Maybe I'm just too tired now to understand the real problem...

> 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

bugs can be fixed in the current stable release, can't they?

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

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

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

The release cycles were way to long, ok. But as for Gnome 2.2 it was quite ok,
at least in my opinion.

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

right, and I wasn't talking about a one year release cycle ;-)
I totally agree with you. I'm just worried about a 6 months release cycle which
isn't possible IMHO.
Correct me if I'm wrong, I accept it if I can see that it's possible :-)

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

Sure, that's my plan.
  
> No, GNOME 2.6 would depend on GTK 2.4.

Then we'll also have a Gnome 2.8 which will depend on gtk2.4. Are there any
plans to release gtk2.6? We'd have Gnome 2.10 ;-)
 
> GTK 2.2 was well underway when GNOME 2.2 started, GTK 2.4 isn't, and
> GTK 2.4 has more new APIs.

i c
and I think that's pretty cool. I'm just not sure how we can easily fix some UI
issues.
 
> 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.

Fine, I don't have any problems about punting features, but I'm not feeling
well about punting bugs :-(
 
> 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.

Yeah, I got your point now, and I remember from GUADEC, where some people
discussed about how the release plan should look like.

Greetings,
Christian