Re: Stricter policy when including BIG modules (was Re: Evolution 2.0 and GNOME 2.6)

[Murray Cumming <murrayc murrayc com>]

On Sat, 2004-01-31 at 20:50, Danilo Segan wrote:
> Hi Murray,
> 
> Murray Cumming <murrayc murrayc com> writes:
> 
> > GNOME's quality control means that there is always a risk that a module
> > might be punted or reverted to a previous version.
> 
> Of course.  But I mentioned that special care should be taken with
> such modules like Evolution: it's a huge program itself, it has over
> 3900 messages to translate.
[snip]
> You missed my point.  Gnome 2.6 is coming in early March. That means
> around one month for translators to complete it.
[snip]
> Yeah, and go back to my point you quote: "significant module (in
> terms of work...". You can even add Totem now to Gnome 2.6 and nobody
> would complain that loud: it's a consisted of 333 messages. And now go
> back and read Evolution count: 3900+ (with E-D-S, gtkhtml, gal, close
> to 5k).  I want to say that Evolution being in and out is not same as
> doing it with Totem.
> 
> In simple words: for such influential modules such as Evolution, be
> more strict and careful when adding it to the core (that was the
> intent of my proposal, not to bind ourselves on unready modules --
> when there's such a penalty, one tends to be more careful about
> choices, I would say).

We have very few must-haves for the release schedule, because must-haves
are an obstacle to time-based releases. One of those must-haves is "an
acceptable level of stability", for instance. I don't think that "being
translated into languages X, Y, and Z" should be one of those
must-haves.

For instance, the accessibilty team had objections to epiphany because
it was not yet fully accessible, but we said that it was OK because
there was no obstacle to it becoming fully accessible in future.
Likewise, evolution will get fully translated sometime, and that will
get into a release as soon as possible because there is no technical
obstacle to it.

However, if the translation status of a module is really bad then the
release-team do want to know about it, for new modules and existing
modules. I don't personally remember anybody making a big fuss about
that for evolution before now, though you say that they did, so sorry
for that.

Also, if the gap between feature/UI/new-module freeze and final release
is not enough for translators then please do say so. I do accept that
the new-modules decision has been FAR too late this time, and was far
too late last time, and I am personally doing everything that I can to
speed that up.

> I'm not pointing fingers at anyone, for I consider this a problem for
> all of us.  But I want us to resolve that and admit a mistake.
> There were hints all over the place of Evolution not being ready (my
> memory may be failing me, but I think both Jeff and you doubted it
> will be ready in time),  but it seems to me that release team, and all
> other participants in discussions actually went by what they *want* to
> happen, and not what's realistic (I don't exclude myself here, I
> wanted it in probably as much as everybody, and that's why I never
> complained about it).

Some people had doubts. So I asked the evolution maintainer and he
convinced us that there was no problem. That's on one of the evolution
mailing lists. But nobody can predict the future and I don't want
anybody to pretend that nothing is wrong when the situation changes.

> And that's why we need policy, so we'd be able to decide without
> doubt if module is to be included or not. It can be as simple as: if 
> we're not sure it's going to be ready and meet Gnome quality
> standards, and it greatly affects work of Gnome subteams, then don't
> include it.

If we required 100% certainty then we would never do anything. The
schedule manages the risk and copes with what happens.
 
> As we always remind others: another release comes in 6 months, so
> nothing to complain about if it's not included right away.
> 
> I'm pointing out at the problem in the release process.  It's not a
> terrible problem, but I think it needs to be fixed, not neglected.
> I'm offering a solution as well, it's just up to the community to
> recognize the problem, and choose a solution (not necessarily mine, of
> course).

I don't think that you have actually suggested any particular action or
process. Feel free to describe it in 1 or 2 official-sounding sentences
so we can see what it feels like.

Thanks again.

-- 
Murray Cumming
www.murrayc.com
murrayc murrayc com