Re: another gnome-libs .02

[George <jirka 5z com>]

On Sun, Feb 18, 2001 at 12:06:19AM -0500, Havoc Pennington wrote:
> I think you're simply wrong about this. A giant lib is "less work"
> only if you don't consider that you've just forced dozens of unrelated
> modules that could have been done in parallel on different schedules
> to work together. Fred Brooks would have your head on a plate. ;-)

You're taking what I'm saying to extremes.  What I'm saying is that say
libgnomeui as it is is more maintainable then splitting it up further.
My point was that if we create separate libraries for every 300 line widget,
releases will be a nightmare.  So no, I'm not suggesting tarring up every
library we know off and naming it gnome-libs.  What I'm saying is that
sometimes more modular may mean more work.  I don't think one or two
widgets will make the library unmaintainable, and frankly I think that
maintaining a couple more widgets then the absolute minimum doesn't hurt much
either.  We're not talking major large components here such as gtkhtml.

> You want to avoid trying to create the Single Giant Huge System, and
> create lots of little useful independent stuff.
> 
> We already have the "require a small change to each widget" case -
> what do you think GTK 2 does? There are thousands of GTK apps and
> hundreds of GTK widgets in numerous modules. But because those things
> are separate, with their own maintainers, we can easily parallelize
> the work, and it will get done quickly and painlessly. If we had all
> of libnautilus-extensions, GAL, libgnomeui, GtkExtra, GtkHTML, and
> whatever else in GTK+ then we wouldn't be _able_ to change anything,
> because we'd be completely swamped as the sole maintainers of this
> enormous load of stuff.

When I was porting g-l to GTK2, it was a couple of hours worth excercise.
That was because I could just do the whole bit at once since I just did vi
*.[ch] and did the change.  If I had to set up buildstuff and all that for 20
different libraries that would have been at least a weeks worth to do.

> > >     - libraries like GAL, libnautilus-extensions, etc. which 
> > >       are not really supported for general-purpose use yet, 
> > >       but allow people to experiment with new widgets and share
> > >       them between some set of apps
> > 
> > Except that these libraries are discouraged for use by apps outside a "chosen
> > few".
> 
> Which is _absolutely the correct thing to do_. Let me say that again:
> it is ABSOLUTELY the correct thing. If a widget is not ready, then it
> should be discouraged for people that don't know what they're getting
> into. If a widget isn't of general interest, then it should be in an
> application-specific module. When it's finished and ready and of
> general interest, then as I've said it should then and only then go
> into a general-purpose lib like libgnomeui or GTK.

Well great, but we're trying to make code sharing possible.  Libraries like
GAL or libnautilus-extentions are not under preassure to clean up into such a
usable state.  It's like the utils.[ch] you write for your module.  No matter
how long it will sit there it will not become usable by outside.  Widgets
could be tested in such libraries, but they need to be stuck into production
bound libraries and cleaned up if they will ever be useful for a wider
audience.

> The stuff in GAL is (mostly) either a hack that's getting merged later
> into GTK/libgnomeui (e.g. paned and scrolled window forks), or not
> finished. So Miguel says he discourages people from using it. As he
> should, because it isn't something you want to use if you're looking
> for a stable lib. But it's fine for the set of apps that are also
> unstable and are prepared to sync their release schedule with GAL.

I have nothing against GAL not being a general use library.  But it shouldn't
be used as an excuse for not having one.  As long as widgets will be in
non-production libraries, we will not get them cleaned up (and thus they will
never be ready for production libraries, and so the catch 22), and people
will duplicate the effort.

> What I'm very, very strongly opposed to is "as soon as we use a piece
> of code in two places, put it in gnome-libs" or "5% of people could
> maybe use this, put it in gnome-libs." That is death. Evil. Bad bad
> bad. Stampeding herd of frothing-at-the-mouth GEGL rolling over us.

Of course this is bad.  Though the 5% figure could be useful.  I mean there
will always be such widgets.  If this is a major component that takes up
20megs of source then no it shouldn't be in gnome-libs.  If this is a 300
line widget which has a sane interface and is actually useful to those 5%, I
think it makes sense to have it there.  5% is a lot of developers.  Again I
think this should be left more up to the task of "are there enough people
willing to do maintanance on this", rather then arbitrairly deciding things
are not utterly neccessary and we should drop them.

> Clear bounds on the libraries. Parallelization of maintenance. Minimal
> interdependencies.

We only have so many people to do maintainance.  By splitting up libraries we
do not gain more people.  Again, I'm not for putting everything into one big lib,
I'm for not splitting this up too much.  And I'm for having some focus on
making widgets usable.

Dropping widgets from gnome-libs means just about death for widgets in fact.
Unless the widget gets put into another library.  Right now we don't have any
other mainstream production libraries for utility widgets.  I'd be happy to
start one if there is consensus on that this should be done and it can take
over some libgnomeui widgets off "lesser" importance.

George

-- 
George <jirka 5z com>
   Patriotism is your conviction that this country is superior
   to all others because you were born in it.
                       -- George Bernard Shaw