Re: GNOME 2.0 Schedule

[Chris Phelps <chicane reninet com>]

When the UI freezes, hackers will feel less inclined to fix things,
Fixing bugs is one thing, but add cool new UI features is a motivator
for a lot of people. If we decide to institute some sort of UI chance
process, that is fine, but it better short as humanly possible or we're
going to squelch the innovation that is Open Source. GNOME is what it is
because it gives people the freedom to develop as they please.

I realize that Sun wants to use GNOME as it's next generation desktop,
and thus would like the community to follow it's lead in becoming a
"commercialized" desktop. To some extent this is an extremly valuable
service to the community. Testing facilities, libraries like atk, etc
are all things that GNOME needs. GNOME needs a UI freeze like I need
another hole in my head. The community is what makes GNOME great, don't
try and cut the little guy out of the loop or we'll end up cutting our
own throats and killing the whole project.

Later,
Chris

On Thu, 2001-10-11 at 12:28, Glynn Foster wrote:
> 
> > I can't see a complete UI freeze inbetween gnome releases as benefiting
> > anybody at all in the world. Among other things it would put all the
> > authors who decide to give in after a 3 month long email bomboing campaign
> > by the Gnome Usability Project and fix the gross bugs in a really awkward
> > situation. 
> 
> One point to be said *for* a UI freeze, however, is that you can be
> pretty much certain that the 1000's of documents aren't broken as a
> result of someone fiddling around with the UI. Why? Each document
> probably contains one or two screenshots and more for some. Each
> document is translated into say 10 languages, with seperate screenshots
> required. That's a lot of breakage in my book :)

-- 

http://glimmer.sourceforge.net - My pet project
http://uberhackers.dhs.org - My personal website

./configure --prefix=/dev/mocha --enable-caffeine