Re: external dependencies

[David Zeuthen <david fubar dk>]

On Thu, 2006-09-14 at 11:04 -0600, Elijah Newren wrote:
> Hi David,

Hi. Sorry for the lag.

> On 9/13/06, David Zeuthen <david fubar dk> wrote:
> > It's really what audience we want to optimize for. There are (at least)
> > two groups of entities that provide the GNOME experience to users;
> <snip>
> > This of course is only one example. I submit this is a trade off and it
> > really depends on who we want to optimize for.
> 
> No, this issue is bigger than target audience.  Testers, documenters,
> and developers often need a development version of GNOME to get their
> work done.  Requiring them to have very recent versions of nearly
> everything on their system is much too high a bar.  In fact, the
> building bar is so high right now that I believe nearly everything
> else in GNOME is currently suffering; the difficulty of building GNOME
> has even taken a large amount of time from some of the more
> experienced developers.  (Note that I'm by no means just blaming HAL
> here; we have lots of issues.  External dependencies in general have
> been the biggest problems in the build area in the recent past, thus
> the proposal to stop depending on cvs versions of those.)

Right. As GNOME is being increasingly integrated with things like the
kernel, HAL, X.org and so forth this is understandable. To me it's still
pretty simple

 - if we want GNOME to be on the bleeding edge wrt. using new technology
   we accept that GNOME packages may depend on very recent external
   dependencies. For example, making 2.18 depend on the HAL 0.5.9 that
   will be out in December.

 - If we want to be more conservative we don't do this. I've raised a
   few scenarios in earlier mails about this. To sum up

   - You'll have ugly #ifdef's in code for several code paths for
     supporting several versions of D-Bus, HAL or whatever. No one
     really wants this

   - It suddenly becomes a huge liability to be part of the GNOME
     release - can't speak for Richard per se, but really, g-p-m largely
     depends on new features in HAL. Too bad he's stuck on HAL 0.5.7
     now, that CPU frequency thing looked interesting

   - Personally, in the past, I've done some development on GNOME
     features in g-v-m, gnome-vfs and whatnot and sending those patches
     to the list before a release. I'll continue to do this but I'll
     probably won't bother sending them to the list until the next
     GNOME development release opens - they will be sitting in the 
     Fedora SRPM and we're back to distributors having increasingly
     big patch sets.

   - Distributors having large patch sets leads to other well-known
     bad things.

I fully hear what you are saying about testers, documentation people,
GNOME developers and application developers wanting to develop on a
recent GNOME. Previously, and today even, the answer for these people
have been things like jhbuild and GARNOME. In today's world where we
increasingly integrate with external projects this can lead to pretty
strange bugs as I've also outlined earlier.

Don't want to flame or anything, but perhaps things like GARNOME can
move to a live-cd / live-usb approach of delivering their software so
users have the right external deps... I mean, there are several good
tools from the distributions to do just this; for example I hear good
things about the Ubuntu live CD infrastructure (Fedora needs to catch up
there but that's another discussion). 

It's also useful to point out that several vendors including Debian,
Ubuntu, Fedora and SUSE are pretty quick at putting new GNOME
development releases out. Perhaps pointing testers to such trees is not
a bad idea, it's not like having > 1 OS on a single system is something
new.

So holding back new and useful features in the name of "some people are
running old OS'es" is just bad. Sorry if this comes across as a flame. I
just don't want GNOME to miss out great new stuff.

    David