Re: more gnome 2 proposal

[Martin Baulig <martin home-of-linux org>]

Alex Graveley <alex ximian com> writes:

> Also, it is important to mention that this would not be a "huge" module.
> We are talking about merging non-ui bonobo, non-ui gnome-libs (tiny
> after the bonobo merge), gconf, oaf, and gnome-vfs into one module.
> Bonobo-ui, gnome-libs-ui (tiny after bonobo merge), and gnome-canvas
> into another. Possibly adding gnome-print and gnome-print-ui
> respectively, but I am not adamant about it.
> 
> Also, given that everything will be merged and component-based, the
> chances for refactoring are immense.
> 
> Wrt complexity of the tree, the fact that everything would 1)
> component-based and b) integrated, means that we can come up with a sane
> tree layout that makes sense for all of the core modules. Not just one
> that makes sense for bonobo, one for gnome-libs, one for gconf... all
> that make sense for the individual package but when taken with all the
> other packages in the system add to a confusing non-uniform mess.

And you're talking about mess here :-)

You're the one who's proposing to create a big, vaguely defined "something"
which has code from a lot of different modules. And you even want to merge
modules into this "something" which are completely separate from each other,
serving different purposes and having their own development cycle.

And as the reason for doing this, you give "something".

Because, ``integration'' and ``component-based'' are both nice words and
of course there's nothing against using these words. But you don't provide
any concrete idea what you mean with ``integration'' and ``component-based''.

This is even worse since you use the word ``component-based'' for at least
two packages which have nothing at all to do with a component system: oaf
and gconf. So you want to do "something" with oaf and gconf.

What you say is not wrong and I'm not criticising your plan, but you missed
the key point of our proposal here:

Whether things are easy to build or not is absolutely trivial and discussing
about build stuff doesn't help us at all here.

Point is to look where we're coming from and where we want to go.

We're just going to release GNOME 1.4 in a couple of days. GNOME 1.4 consists
of a number of different module. These modules have different purposes,
different maintainers and also different release cycles. Sure, things will
stabilize a lot after GNOME 1.4, but I still see oaf, gconf and gnome-vfs
as three different libraries with different purposes and each of them
deserves the right to stand alone.

We want to API freeze GNOME 2.0 in July, so we just have three months from now.

What our proposal contains is an actual working plan how to go from the
current GNOME 1.4 to GNOME 2.0. It describes which CVS modules to create,
how to set up stuff that it compiles, how the dependencies should be, just
everything. You can download my tarballs or even that CVS repository from
my ftp server and you'll have a working system.

Having a working system means that you can immediately start spending your
time to look at the code and the features and to actually do productive
hacking work. There are a lot of things which have to be done and I use neither
this ``i'' nor this ``c'' word here.

I just say that we need to make the current Bonobo usable and working with
the current gnome-libs HEAD and the current GNOME 2.0 setup. If you actually
looked at my tarballs and the README which is in the same directory on the
ftp site, you'll find out that it actually contains an RFC concerning Bonobo.

I wrote there that we can make the libgnome-2 <-> libbonobo-2 and the
libgnomeui-2 <-> libbonobo-2 dependencies either way - one way a bit more
difficult than the other, but both are possible. And I also describe how
that's done. So if you guys want to do something productive, you can for
instance look at this and talk about which way is best instead of talking
about what is easier to build.

Another big issue with one big module is that maintainer section.

This afternoon, I asked Elliot Lee whether he'd accept a patch for ORBit2
which makes it create a pkg-config file and I also offered him to write and
test such a patch. I'm not talking about whether it's good or wrong to use
pkg-config here, we discusses this a lot a long time ago and decided to use
it starting with GNOME 1.4.

Having ORBit2 install a pkg-config file is necessary because other packages
will depend on ORBit2 and so they need to list ORBit2 as a dependency in
their pkg-config files. A maintainer which tells me that the easiest way to
do this is to either fork ORBit or to use another ORB because he don't want
to have this in his module doesn't help us here in any way.

Do you really expect that this will get _better_ if you make modules bigger ?

What happens if Michael or Miguel wants to fix a bug somewhere in Bonobo's
menu merging code, but instead of just making a new release of "their"
libbonoboui-2, they need to talk with all the other maintainers of oaf, gconf
and whatever else is in that tarball, try to find a date which suits all of
them best and then coordinate a release of this big "something".

And what happens if I just discovered that something got broken in libgnome
two days ago, but luckily the release I did three days ago worked just fine.
So what to do - do you prefer getting that bug into the big "something" or
live with your bug in Bonobo until I fixed mine in libgnomeui ?

With our proposal, you just make a new release of your module and don't worry
about the rest. And once we're in binary freeze you can't even break anything
with it. And if you absolutely need to release all packages at the same time
you can still try to get all its maintainers into IRC at the same time and
then coordinate the release.

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)