Re: Moduleset Reorganization -- Take two

[Robin Sonefors <ozamosi flukkost nu>]

On tis, 2010-10-12 at 14:03 -0700, Sandy Armstrong wrote:
> On Tue, Oct 12, 2010 at 1:31 PM, Murray Cumming <murrayc murrayc com> wrote:
> > On Tue, 2010-10-12 at 15:03 +0200, Vincent Untz wrote:
> >>
> >> Good point. It's fair to expect projects not using the GNOME
> >> development
> >> cycle to publish a schedule with freezes.
> >
> > You would allow modules in the module sets that don't follow the GNOME
> > schedule? Then it loses all meaning. Once again, the purpose of the
> > release schedule (of which the module sets are just a part) is to
> > release software.
> 
> I agree here.  I'm not sure how the i18n and docs teams are supposed
> to do their jobs if they have to track dozens of different schedules.
> 
> Maybe those teams should only devote resources to an application on
> the occasion that a release matches up with the GNOME schedule?  This
> would allow for apps to have more or less frequent releases, but at
> the same time encourage them to have their releases match up with the
> GNOME schedule whenever possible.

With every new GNOME release, we would compose the release of the latest
stable version of all the applications, right?

So when we tell the application developers to pick a release to be part
of a stable GNOME and to be mentioned in the release notes and so on,
why don't we require that specific version of that application to follow
the UI/string freeze for the 3.x.0 version of GNOME, and that the
application releases a stable version - either a new stable, or a point
release - when tarballs are due, if there are changes such as new
translations?

Thus, if you want to have a 4 month release schedule, that means you'd
pretty much have to release with GNOME once every 18 months, and for the
two gnome releases in between you'd just release updated translations
for months old stable versions. If you want to have a 12 months release
schedule, you'd still have to provide point releases every 6 months.

Applications would still have the option to ignore the schedule for
GNOME's unstable releases, as well it's bugfix releases.

As many distributions are on a "GNOME + a few weeks" schedule these
days, it should be in the application developers' interest to at least
do a bug fix release at or around GNOME release time, so it shouldn't be
too much of a burden to fulfill.