Havoc's Blog

Of course I have to agree with Luis
that sticking as close to trunk as possible is best – that’s one of
the big reasons we switched to the 6-month time-based releases, to
keep “what the developers are working on” and “what users are using”
as in-sync is possible.

If you want to see wasted effort, have a look at the enormous
backport-fest in the vendor kernels… the kernel project is really
pretty broken in this respect. With GNOME, even if people ship 2.6
rather than 2.8 it’s not that bad. Or not as bad as the GNOME
1.4 days when we spent a year trying to get people to stop piling
patches on 1.4 and finish 2.0. 😉

I think the main reason much of XD2 didn’t make it upstream was that
it was done behind closed doors without buy-in and much of it was done
in a pretty hacky way (for understandable reasons). If we instead take
the approach of first making the change in 2.8 in an
upstream-acceptable way and then backporting to 2.6, then we know
stuff won’t be lost.

It’s a little bit dangerous to have people planning to ship 2.8 when
2.8 is released well into the OS freeze cycle; what happens is that if
2.8 is for any reason delayed, you can’t back down to 2.6 during a
freeze, and you would be forced to ship a 2.7 beta (or put a big
unexpected delay late in the OS release cycle, which may not be an
option in a still server-driven world). GNOME is safer than any other
project I know of to do this with, but it’s still a little scary.

This whole discussion may be opaque to others: context is, Luis and I
were discussing earlier whether to base the next OS releases on 2.6 or
2.8. Red Hat hasn’t really decided yet.

BTW, I agree 100% that the foundation should hire people to do admin
work; it just pains me to see Jonathan and Owen spending a bunch of
time on that. Hiring developers is different.

(This post was originally found at http://log.ometer.com/2004-04.html#9)