Re: getting on a longer release cycled

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

... but all that is secondary to the bigger concern that GNOME is
increasingly disconnected from its users. IMHO, but there you have it.


Andrew Frederick Cowie
Operational Dynamics

Organizational strategy, change management, and technology innovation to
help clients worldwide prevent crisis and improve operations.

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]