Hi David, On 9/19/06, David Zeuthen <[EMAIL PROTECTED]> 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. _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
