Re: Thoughts on GNOME 2.0

[Havoc Pennington <hp redhat com>]

George <jirka 5z com> writes: 
> I think you are seeing this too black and white.  We can do all.  Perhaps not
> in the same quantity.  Thisis not a binary operation, it's not all or none.

The reason I'm seeing it that way is that I don't think it's a good
idea to have apps ported to a library that's still changing a lot, and
try to work on the apps at the same time.

i.e. I would advocate a) freeze libs then b) port apps to them.

If you are willing to throw it all up in the air and hack on apps and
libs at the same time, sure it's not as black and white, but you also
have to spend 3 hours compiling every morning, and anytime you change
a lib you have to spend 3 hours compiling and also fixing any apps
that broke to avoid getting flamed. Or alternatively, you leave the
apps broken and the tree never builds. I found this really awful
pre-1.0. With a project several times larger in terms of both code and
people, I can't imagine it.

Anyhow, sure if you keep them both unstable at once then it's not as
black and white, I agree with you.

> We should work on everything, however perhaps we should set a focus.  However
> I still don't see how you will manage to "enforce" a focus since there is no
> authority over gnome (thank god).  What we need is to discuss what needs to
> be done, but we can't stop people from working on new features in the user
> platform even if someone arbitrairly decides that the focus should be the
> devel platform, and same in reverse.

That's not true. If gnome-libs is frozen and someone checks in a
feature, we revert the patch. Simple as that. Same for user apps.

If they want to do the feature in a separate module, then no we can't
enforce that, and in fact I'd encourage people to work on whatever
they think is a good thing, because that's what moves us forward.
 
> 1) Decide what are the biggest ills (not by such broad categories as yours, but
> more fine grained).
> 
> 2) convince people to work on those issues.

Don't agree because I want libs to (at least mostly) freeze before
porting apps to them.
 
> I thinkt he proposed list as stated in the previous mail was quite good and
> far more specific then yours.

I think it was good too, but I think this more black and white
big-picture conflict exists for abovestated reason, so feature list
depends on resolving that bigger picture.

Havoc