Modules must be stable first? [Was: Evolution 2.0 and GNOME 2.6]

[Jeff Waugh <jdub perkypants org>]

<quote who="William Jon McCann">

> Perhaps, in the future, a new module can only be proposed/accepted for
> inclusion in the Desktop if it is *already* in an acceptable state.  That
> way "being ready" or "not being ready" at the last minute is no longer an
> issue.

I really do agree with this, but I think we've chosen to take a risk on a
number of modules in the past for good reasons, and mostly found success.

For instance, Epiphany was a pretty sizeable risk, but there was *massive*
support for having a browser in the Desktop release, so it stayed on the
list even though were weren't fully sure it would be ready - as it happens,
I was not entirely happy with the decision right up until our beta release!
However, I think it's pretty clear now that we made the right decision. We
have a kickarse browser with a maintainer team that pays attention to the
details, and to larger issues in GNOME (they were testing the new GTK menu
and toolbar API for a long time, etc).

So, Evolution was a big risk, but we have a huge amount to gain through its
inclusion in the Desktop (and hopefully in the Platform, for e-d-s). The
other tough cookie in this release is GTK+ -> we're waiting for it, we're
depending on it... That's quite a big risk, but the payoff is the new menu
and toolbar api, and the long-awaited file selector. Very tough call. I
would love to be a total fascist in this regard, and say that we will never
depend on unstable GTK+ features ever again! But can anyone guarantee that
the risks/benefits may weigh up in the future? Not really. :-)

With the time based release process, we don't guarantee feature inclusion.
So when new stuff isn't ready, it's cut. Luckily, maintainers have been
incredibly realistic about software readiness, so the release team (or any
one else, really) has never had to propose or do this themselves. :-)

There has been a lot of feedback on timeliness issues during this release,
particularly from the i18n team, which has been really useful. Perhaps next
time around we can have a running 'viability rating' or reporting system for
proposed modules, so everyone can adjust priorities as we go along. We don't
want to add to much extra work for maintainers, or levels of bureaucracy
into the process, but this kind of approach may work. Let me know what you
think -> I'm sure there are other ways of going about it too!

Thanks,

- Jeff

-- 
GVADEC 2004: Kristiansand, Norway                    http://2004.guadec.org/
 
         "Applications are just kernel testcases." - Andrew Morton