Re: more gnome 2 proposal

[Maciej Stachowiak <mjs eazel com>]

Alex Graveley <alex ximian com> writes:

> Hi,
> 
> On 10 Mar 2001 18:39:56 -0500, Havoc Pennington wrote:
> > I think the largest and most substantive point of disagreement right
> > now is library packaging, i.e. lots of small modules vs. two big
> > modules. 
> 
> My personal view is that this is a major mistake. You run the risk of
> continuing the tradition of difficult builds and complex dependencies.
> 
> Keeping everything in one or two modules is nearly guaranteed to fix
> both problems.
>

I disagree. Huge modules are difficult to build. This is because for
any given module, there's only a few people that really pay attention
to build stuff, and the bigger it is, the harder it is for these few
people to keep things building well and have time to do anything else.

In fact, gnome-libs is the main module we have that's a big grab-bag
of various stuff, and it's one of the hardest to build.

On the other hand, there are good solutions today for building many
modules easily in the correct order. At Eazel we have a setup where I
can just type `rebuild' and nautilus and all it's dependencies get
checked out and built off the correct branches and in the correct
order. And it's always building, because we keep a tinderbox going
that sends us whiny mail when it does not. Alternately, I can type
`gnome_1_4_beta2' followed by `rebuild' and build the whole GNOME 1.4
beta from tarballs.

I can't really imagine a simpler build experience. 

If other people are really having a hard time getting compiled, we can
distribute our eazel-hacking setup more widely (it's available but we
don't publicize it a lot because it's pretty customized for Eazel's
environment, and we assumed other people had their own good build
solutions).

It's also important to recall that the set of people who build GNOME
from source with any regularity is vanishingly small - 99%+ of users
get everything from binary packages. Even most users using
bleeding-edge packages like Nautilus and Evolution use binary packages.

For these users, having things split up nicely is much better than
having one big honking package. Their needs are much more important
than the relatively small handful of people who actually build stuff
from source.


> 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.
> 

But it _does_ hinder the ability to release and update these
separately, and to manage cross-dependencies effectively. Please read
the section in the proposal about how Microsoft keeps different parts
of the API split up and cleanly layered, and why. Do you think we're
so much better at release engineering than Microsoft, and so much
better at anticipating future changes, that we don't need to take the
prudent measure of keeping the development platform well-factored?

Read the parable there about COM, MFC and ATL. This exactly parallels
the stories of gnome-libs and imlib and GtkXmHTML - except Microsoft
wasn't screwed, because they'd kept the COM layer and the MFC layer
well separated.

> 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.

That's not the argument at all. Any change you make to a library, even
a bug fix, introduces a risk of new bugs. Having a critical bug in zvt
right now means you have to release all of gnome-libs to fix it -
which means that many changes which are in general *not* critical,
also go out. This means unnecessary risk. It also means an unnecessary
download for users using auto-updaters - if they only need a fix from
Zvt, why should they have to update the whole gnome-libs package?

But this is hardly the main argument. It's just one adjunct argument.

>From a release engineering perspective, it's obvious that having the
ability to release different parts of the platform to deliver fixes on
different timetables, or to start experimental lines of development on
different timetables, is the right thing to do.

I have worked professionally as a release engineer, which I doubt many
people in the GNOME community have. I've also been doing a lot of the
release coordination work for GNOME 1.4. And from what I've seen in
both cases, it's obvious that big monolithic packages are harder to
manage and make it harder to deploy targeted fixes.

> 
> 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.

Whether things are in one module or many does not affect the platform
compatibility policy (which we really need to get written up and
officially adopt).

> 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.

I don't think the case where you need to know many library versions in
details to identify a bug comes up very often. I have personally never
seen it.

On the other hand, being able to vary versions of different libraries
independently can be a powerful tool for pinpointing the bug. Many are
the times when I tried cvs checkout -D "one week ago" on different
modules in turn until a bug went away, and this allowed me to figure
out what piece of code the bug was likely to be in. This would be way
harder if everything was in one big module.

> 
> 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.

No, it would make it way harder to start working. Right now to
contribute to GNOME, you only need to know one module and understand
the APIs and conventions and design there. For complex modules, it
gets too hard. We have a lot of people right now getting involved in
bonobo and gnome-vfs and the like, because they only have to
understand that one small piece of the puzzle. If the barrier to entry
were understanding the whole GNOME platform, it would be almost
impossible to become involved in GNOME as a weekend hacker. Notice
that you don't see a whole lot of people getting involved in
gnome-libs, because it has already passed that complexity threshold.

The bottom line is that gnome-libs is a huge mess, whereas individual
purpose-specific libraries are much better managed. Dumping all of
these well-run projects into one disastrous already messy module will
make things way way worse and is a step in the wrong direction.


Regards,

Maciej