On Thu, 2006-09-07 at 13:23 -0600, Elijah Newren wrote: > Not sure if I'll paraphrase him correctly, You came close enough that I shan't quibble :) ++ This is what I've experienced in language binding land (and probably the story I told Elijah that he's paraphrasing): The people I work with on java-gnome won't be able to hack on GNOME 2.16 specific bindings until we have GNOME 2.16 desktops on our systems. My systems are otherwise production (in the sense that I use them to do business so I can't afford to have them hideously broken (s/business/what you do for a living and kinda want your computer working/ as you see fit). The others are in similar situations. Which means that we have to wait until the various distros that people use make a release that has a reasonably bugfixed GNOME 2.16 in it so they upgrade to it. Key point: that might be a while; 3-6 months at least! Meanwhile GNOME is movin' on. And then we have to do our porting work (if I can actually find anyone interested in doing so), and then do testing to get that work out the door; by the time THAT is ready it will probably be *past* the deadline for the next release cycle, so by the time our work on 2.16 features hits a distro it'll be the cycle *after* next. And it's not until THAT point that someone can get the code I've written to actually work on actual *applications* ... which in turn won't land in a distro until when, exactly? And meanwhile, GNOME continues movin' on. [That should be a song or something] We regularly have people showing up who are asking us questions about gtk 2.6 and using a version that is *FOUR* cycles old. We can't support that as we've long since moved on from there (shit, the people who wrote that code aren't even involved anymore), with the result that ISV developers are left out in the cold, and there's no momentum or support for new developers. [Yes, I realize that there are ways to cut corners off our iteration time. (making it easier to build from source; leveraging the .defs files that the pygtk guys use, etc). Working on it. But the point remains: people aren't using code we write now until 6-18 months from now] ++ I wouldn't dream of critiquing the GNOME community's hard won reputation for delivering code when it says it will. I also realize full well that six month time based releases got GNOME out of the 1.4 doldrums which makes it a religion that few are willing to give up. But releasing when you say you're going to does not imply that that the date has to be on a short period from the last one. Release engineering takes a LOT of work, both on the part of the people doing the tarballs and such through to people trying to keep up with translations and documentation - let alone the slavery that people doing the packaging in each distro have to put up with. It would therefore seem worth considering that we reduce the amount of time this takes as a percentage of cycle time - and one way to do that would be to lengthen the cycle. [And, note that in quite a few cases its the same person doing the work throughout the stack, meaning time spent on release engineering is time taken away from wizard hackery and innovation]. ... but all that is secondary to the bigger concern that GNOME is increasingly disconnected from its users. IMHO, but there you have it. AfC Sydney -- Andrew Frederick Cowie Operational Dynamics Organizational strategy, change management, and technology innovation to help clients worldwide prevent crisis and improve operations. Website: http://www.operationaldynamics.com/ Blog: http://research.operationaldynamics.com/blogs/andrew/ GPG key: 0945 9282 449C 0058 1FF5 2852 2D51 130C 57F6 E7BD Sydney +61 2 9977 6866 New York +1 646 472 5054 Toronto +1 416 848 6072 London +44 207 1019201
Attachment:
signature.asc
Description: This is a digitally signed message part