Two things...

[Elijah Newren <newren gmail com>]

Hi guys,

So, I was thinking of sending the below email to d-d-l and asking for
comments, but I'm beginning to wonder if I'm off base or am unaware of
various policies that may exist (or if it's just flat not necessary). 
So, I'd like some comments before I do so...

Also, I mentioned the idea on d-d-l of putting together a single place
that has all the expectations of modules in the various release sets. 
I'm willing to work on putting that together in a few days when I have
a little more time, if there aren't any objections or alternative
ideas.  (To perhaps explain more of why I think it'd be
useful...Damien commented to me in IRC that "I agree the rules [for
what is required of modules in a release] are not clear. I never know
what I have to do with branches wrt GNOME for example."  To which I
responded that I'm not so sure I know all of them either, despite
trying my best to learn them and even being on the release team.)

Thanks,
Elijah


Hi everyone,

As brought up recently, most modules in the desktop make new stable
releases (by which I mean x.y.0 releases, i.e. not just bugfixes,
documentation, translations, etc.) at the same time as new Gnome
releases.  There has been no policy about making a new stable release
earlier than that time, but it has been suggested that perhaps we
discuss this.

The core issue is: If modules are deemed stable enough by their
maintainers, is it okay for them to release them as such ahead of the
Gnome schedule, so long as they stick to all the appropriate freezes? 
Or should they defer labelling any release as stable until the time of
the next big Gnome release?

The reasoning for waiting would be to allow the translation,
documentation, bugsquad and other teams to have a greater opportunity
to make sure that all "stable" releases have a sufficient amount of
support and work from them.

FWIW, I'm of the opinion that we should allow maintainers to make
stable releases early if they wish, but that they should continue to
make point releases (in order to include translations, documentation,
etc.) and that the various teams should not feel a need to worry about
heavy support for those early releases (so that they can instead
concentrate on whatever is optimal for making the next big Gnome
release rock, including the relevant _point_ release of the given
module).  Doing things this way would mean one less rule to keep track
of (thus allowing maintainers to do whats best for them), wouldn't
change how the various Gnome teams work (other than telling them to
not worry about preliminary stable releases, if they happened to be),
and would still ensure that our Gnome releases
are as good as possible.  It also matches my slant from my bugsquad
background, knowing that more people will try out a "stable" release. 
Of course, there's the downside too, in that some "stable" releases
are not as well supported as others which may seem strange.