Re: Remove GnomeMeeting from Gnome module list?

[Elijah Newren <newren gmail com>]

Hi,

It looks to me like we've actually hit on a gray area.  Both sides
could be right, because as far as I can tell, the issues being
discussed aren't actually spelled out anywhere that I can find (I'm
looking at http://www.gnome.org/start/2.9/ and all the links at
http://developer.gnome.org/dotplan/).  Yes, it appears GnomeMeeting is
functioning different than other modules, but not in a way that breaks
any explicitly listed rules that I can find...  (more below)

On Tue, 18 Jan 2005 20:24:09 +0100, Danilo Šegan <danilo gnome org> wrote:

> > We are not playing our own rules. Nobody has never said that each GNOME
> > component should have a new release at each GNOME release, but perhaps
> > the release team should clarify on this.
> 
> Of course it needs not have a new release for every Gnome release.
> But you do make new releases at random times.  The only release where
> GnomeMeeting and Gnome coincided was on introduction of GnomeMeeting
> into Gnome 2.4.
> 
> 1.00 came around 1 month before 2.6, to be updated with 1.0.1 before
> the release.  How do you make use of Gnome-wide freezes here, I don't
> understand.  (And I complained about it at that time, you might have
> forgotten about it.)
> 
> 1.0.2 came about 6 weeks or so before 2.8.  GTP team complained about
> that as well, but it's hard to keep up with everything there as well,
> especially when Christian Rose was too busy (and he's still the most
> dependable person in GTP).

So, the major issue appears to be making stable releases before the
rest of the modules in the release set do.  It does make sense to give
i18n, a11y, u7y (usability), q15e (quality assurance), (sorry, I can't
resist adding to the abbreviations) and the other teams time to work
on modules; however, I can't find a rule that says stable releases
can't be done before.  So long as all the appropriate freezes are
followed for a given release, it appears that this doesn't go against
any policies.  Perhaps that should be changed, but that is something
we need to discuss.  Or, perhaps there really is a policy against it
and I just missed it (but if so, we really need to make it more clear
because if I don't know about it and I've tried my best to be up on
this stuff, then others are certainly missing it).

> Not doing a tarball for 6 weeks which are there in the release cycle
> exactly for translators and documenters prior to Gnome release, means
> that translators' and documenters work wouldn't be seen.

Yes, if we don't decide on making some policy against early stable
releases, we should try to push on releasing extra tarballs even if
the code isn't changing.


Elijah