Re: 2.4 Proposed Modules - 2 weeks left

[Havoc Pennington <hp redhat com>]

On Tue, May 06, 2003 at 12:19:59PM +0100, Bill Haneman wrote: 
> This work is likely to be non-trivial.  Unless we have identified
> someone who will do this work I am very uneasy about putting a browser
> in GNOME 2.4.

I still haven't heard and don't understand how having the a11y work
unfinished in 2.4 hurts anyone or causes any long-term problem.
We know the work can be done, we know there is no way we're going to
adopt a XUL frontend into GNOME instead.

If we know we're going with a gecko-based native-widgets browser, all
keeping epiphany out does is slow down progress in a11y and other
areas.

If you think we should maybe go with some other browser strategy, then
what browser do you think we might end up with in 2.6?

If you think it's definitely going to be epiphany, we need to get it
in and start getting it used and start iterating it in real
releases. Delaying that just shoots ourselves in the foot.

What you're doing by saying we can't ship anything without the a11y
feature is making part of the release feature-based instead of
time-based. And feature-based is something we've explicitly abandoned
for *very* good reasons.

The way GNOME releases work is that we stabilize and ship the features
we have on a time-based schedule. If the a11y feature for the browser
isn't done then fine; it doesn't ship. But we still need to ship what
we have.

Without paid employees for GNOME we can never be feature-based,
because we can't guarantee that any *specific* feature gets done, only
that lots of cool stuff will happen. We still need said cool stuff to
go through stabilization cycles and have released branches. Otherwise
it doesn't get to users.

We can't afford the luxury or the handicap of keeping out perfectly
good functionality. We need to be dashing forward at some factor above
1x the speed of Windows and OS X, if we plan to catch up someday.

Doing things the right way is still important; putting in some wholly
wrong UI, or flawed architecture, or adopting a package with a
contrary maintainer, all probably slow us down. There's a reason for
our criteria for inclusion. But having something unimplemented (yet
possible, and that everyone is open to) does not slow us down that I
can see.

Remember, the whole point of frequent releases is to keep what
early-adopter users are using and what developers are developing as
close together as possible, because that fuels the open source
process.

Havoc