Re: Remove GnomeMeeting from Gnome module list?

[Murray Cumming <murrayc murrayc com>]

On Wed, 2005-01-19 at 13:52 +0100, Danilo Šegan wrote:
> > On Wed, 2005-01-19 at 10:33 +0100, Danilo Šegan wrote:
> > > I still don't know _how_ does it benefit (so I still don't see a
> >> reason for it being in the cycle)?
> >
> > Translation, documentation, UI review, testing, bug-triaging,
> > integration, marketing, etc. Because those people work on the modules on
> > the list.
> 
> Yes, they do, but are UI changes allowed between 1.2.0 and 1.2.1?

No, but recommended UI changes can be made in the unstable branch,
whenever that happens. It's nicer when it happens as soon as possible,
but it is not essential.
 
>   How
> does 1.2.* integrate with features that came only 1 month after (1.2.0
> was released a couple of weeks before the feature freeze), without
> breaking feature freeze itself?

Ditto.

> All of these teams would have to work outside their schedule

For some teams, they would sometimes have to wait a bit longer for
implementation. For the translation, documentation, and marketing teams,
they don't need to wait.

>  (i.e. UI
> review would have to be taken as soon as new Gnome release cycle
> starts, testing and bug-triaging would be more useful early in Gnome
> release cycle [for stable module releases, instead of late in the
> cycle for stable Gnome release], etc.), because a module is working
> outside Gnome schedule.

I don't see how testing and bug-triaging would be so much more useful if
the module was not already declared stable. 

Obviously, we think it's beneficial to follow a time-based schedule as
much as possible. But we don't think it's a disaster if a module can not
follow it completely. By all means, encourage people to follow the
schedule more, but don't expect us to disown them if they don't agree
what's best for them.

> So, I think this is harmful for those subteams.

It might be a little frustrating, but it's the module that suffers the
delay. I don't see how the sub-teams suffer that much. By all means,
encourage module maintainers to work with the schedule and the sub-teams
as much as possible, but I don't think you can persuade us that we would
be better off if they stopped trying to work with them all together.

If were uncompromising, exact, and demanding, instead of seeking
consensus and cooperation, then we would not be able to work together at
all. There would always be some rule that somebody did not agree with,
or could not comply with. What we have works well, I think.

>   You seem to disagree,
> and we're pretty much done with that.  
> 
> If, otoh, UI, feature and string changes are allowed between 1.2.0 and
> 1.2.1,

They are not.

>  why not simply release them as 1.1.0, 1.1.1, and wait for Gnome
> release to come out with 1.2.0?
> 
> If we only think of how a certain module benefits, then why not add
> all the other programs to the module list?  I.e. lets add Gimp,
> Gossip, Gnumeric, Rhythmbox, Straw, you name it (there're around 200
> modules with translatable content in Gnome CVS, and probably many more
> without translatable content).  They'll all benefit the same way
> (translation, documentation, UI review, marketing, integration,
> testing).  But they'll lose something too (independency), and they'll
> have to cope with that. IMHO, at least.

Yes, they would all benefit from this, and we encourage them to organise
themselves into release sets that can be on a schedule.

But we choose a finite list of applications that best meet user needs,
and we don't choose 2 applications that do the same thing. And the sub-
teams, with their finite resources, consider these modules to be high-
priority.

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