Re: external dependencies

["Elijah Newren" <newren gmail com>]

Hi David,

On 9/19/06, David Zeuthen <david fubar dk> wrote:
<snip>
>  - 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

several versions?  That sounds like you're stretching things a bit to
make your point.  ;)  I don't see why supporting more than two
versions of HAL would be necessary; even two should be worst case
scenario.  I also don't see why we would need support more than one
version of D-Bus.  Yes, though, #ifdef's are ugly and should be used
sparingly.  I'll give you that.  :)

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

It sounds like you still think my proposal was "use HAL 0.5.7 for
Gnome 2.18.x".  That's not true.  I'll try to do a better job of
clearing it up this time.  My proposal was "don't allow development
versions of Gnome to depend on HAL > 0.5.7 *until* discussion has
occurred on d-d-l about depending on a newer version, consensus is
reached, and any potential build issues are addressed so we don't hurt
the effort of unrelated testers, documenters and Gnome developers."
You'll note that I have updated
http://live.gnome.org/TwoPointSeventeen/ExternalDependencies due to
this discussion so far; you have done very well at pointing out the
strong benefits of newer HAL and have convinced me that we should try
to find a way to allow hard dependencies on newer HAL during the
2.17.x cycle.  At this point, I'm just arguing that steps should first
be taken to avoid negatively impacting the work of others.

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

Agreed, these are negatives we like to avoid.  Point well taken.

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

Using a bleeding edge OS, either via live CDs or via repositories like
Rawhide, are definitely viable choices for some people for getting
their work done.  However, requiring it of all developers, testers,
and documenters would eliminate many of them (including me[1]).  I
hope it doesn't come across as a flame, but eliminating lots of
contributors (and making the work of others harder) is just bad.  I
don't want GNOME to miss out on the contributions of many, just
because we can't find any alternative way to allow some great new
stuff in.  ;-)

So, let's try to find a way to get great new stuff in without making
the job of (unrelated) testers, documenters, and developers more
difficult (those working HAL related stuff, obviously, will have to
deal with the issues of being on the bleeding edge).  I think there
have been some suggestions already, from various tweaks of jhbuild and
GARNOME to additional #ifdef's in a few modules.  There may be other
possibilities.  So, thoughts?  Suggestions?  Comments?  Patches?


Cheers,
Elijah


[1] The reasons are just boring details.  However, for the really
bored people out there: My machine situation sucks right now.  The
sysadmins at school have given me almost full control of the machine
in my office, but not complete control.  My home machines range from
dead to incomplete for the most part; short story is that only one can
run a desktop environment and for various reasons it just isn't an
option for this.  My financial situation isn't such to be able to just
change this right now with a few hardware purchases.  There is
something in the works that is supposed to fix this "soon" (TM),
however this is my situation until then.