Re: Remove GnomeMeeting from Gnome module list?

[Elijah Newren <newren gmail com>]

On Wed, 19 Jan 2005 14:15:03 +0100, Murray Cumming <murrayc murrayc com> wrote:
> 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.

I agree with Murray here.  I believe the problem, Danilo, was that you
felt obligated when an early stable release was made to instantly
switch tasks and immediately try to work on that module.  That
obviously has caused you some problems.  I believe that you should
instead consider early stable releases outside your scope and
concentrate on the relevant _point_ release of that module that will
be made to coincide with the next big Gnome release.  That's my
opinion, anyway.  And yes, we will do better about reminding modules
and sticking up a page with all the expectations we have as discussed
previously in this thread--in particular, mentioning that point
releases do need to be made even when code hasn't changed in order to
incorporate any additional translations or documentation.

Cheers,
Elijah