split already done, make it for real

[Gediminas Paulauskas <menesis delfi lt>]

On 11 Mar 2001 00:49:42 -0500, Alex Graveley wrote:
> Keeping everything in one or two modules is nearly guaranteed to fix both
> problems.
> 
> It is important to keep in mind that having everything in one or two CVS
> modules does not in any way influence our ability to generate as many
> libraries as we want, or as many binary package descriptions that make
> sense. It also does not hinder the ability to have a maintainer for a
> given functional area.
> 
> Your major argument for further splitting the tree is that if bugs are
> fixed in, for instance, ZVT, it would be necessary to wait until the next
> major release of Gnome. This is not the case as new tarballs could be
> pushed every month or so with only bug fixes and a bumped build number.
> Keeping the API frozen between major releases is key, but this is what
> everyone is already advocating.


Let's look and use the work already done. Look at common Debian practice --
split every library source tarball into two packages -- library itself and
-dev package for developer is obviously the Right Thing. Furthermore,
tarballs are more splitted -- some apps have large parts which are
platform-independent (-data, -common, -doc packages).

With gnome-libs thing, there are such packages in Debian from one tarball: *
libgnome32, libgnomeui32, libart2, libgnomesupport0, libgnorba27,
libgnorbagtk0, libgtkxmhtml1, libzvt2, gnome-bin * libgnome-dev, libart-dev,
libgnorba-dev, libgtkxmhtml-dev, libzvt-dev * gnome-dev-doc, gnome-libs-data

This is almost the same that is written in proposal by core GNOME hackers,
so it should be the right thing to do. It was so easy to drop some of these
packages: gnorba, gtkxmhtml, zvt, if they were separate at first. Just
change the dependencies in the next version. Users can download only the
thing that actually changed.

It is easier to maintain dependencies than to keep deprecated things and
provide compat libraries in the big package.

> What this does mean is that development for Gnome becomes a hard target
> for third-parties. You would be able to develop against the currently
> released frozen Gnome API, not whichever API is current for a module, or
> whichever version of packages a given distibution decides to ship.

For third parties we are releasing GNOME 1.4 these days. It is not a moving
target anymore. Someone still develops against October GNOME (1.0.55), they
just don't use the great features, but users can use that app with latest
1.4 libraries.

> In addition this means that complex bugs become easier to track as you can
> narrow bugs to between major or build releases, not a certain version of
> libgnome, a certain version of libgnomeui, a certain version of
> libgnomecanvas, etc.

You discover that it is not a bug in your app, but instead in gnome-libs
1.2.7. Then fix gnome-libs, release 1.2.8 and make your app depend on that
version. Is it that hard? It never means " a certain version" -- just "this
version or above".


> Also, I believe that blurring the lines between existing core modules
> makes for a more uniform interpretation of Gnome, one which would allow
> contributors to easily come up to speed and start working.

Again, the other way. If it comes a person who knows how to do graphics very
well. So, of course he starts to work on libgnomecanvas, libart_lgpl or
gnome-print-core. That module is rapidly improved and can be released often,
while libzvt is so good it does not need any change for ages ;) But if there
comes the rxvt author saying "I gave up developing it, now I want to
use my experience to improve gnome-terminal", than you can say:
"look at libzvt, you probably do not need to worry about anything else".

Which scenario is easier to start with? ever looked at
gnome-libs/MAINTAINERS file? it lists 26 people, although very little work
is done for that.

so, here are arguments for splitting into as many modules, as appriopriate.

-- 
Gediminas Paulauskas

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers