[gst-devel] Doing new releases

[in7y118 at public.uni-hamburg.de]

Quoting David Schleef <ds at schleef.org>:

> I've been tracking the bug list for a while, and
> it doesn't look like there's much that applies to 0.6 that people
> are likely to work on.
> 
People from our team are not very likely to work on anything 0.6 I think. The 
core guys (you, Ronald, me, ...) are much to excited with new stuff to work 
on "old" branches (where you aren't even allowed to commit anyway) and the 
others are much too scared (used losely here to mean all the reasons one could 
think of) by the codebase to backport anything.
As an example: People tried to backport alsa by copying the .c file over. That 
didn't work, they stopped.
So I think the stable branch is pretty much dead from a development standpoint. 
Did anybody even bother adding useful error messages to gst_element_error yet? 
It's been the most important outstanding issue for three months at least.
So release the accumulated bugfixes from bugzilla every time there are enough 
of those and do the other stuff.

As a thought for the future I think it would be good if we adopted GNOME 
standards for the 0.8 release. We should release this thing as stable and then 
work for the next weeks/months on stabilizing that thing. Do some stable 
releases and such. And after the new bugs don't become more and all important 
stuff is fixed, we release one last stable release and branch off to 0.9 from 
there. But don't branch off 0.9 with 0.8.0 or you end up with everyone 
developing on HEAD only. And don't close stable cvs for everyone. Two things 
I've learned: Nobody likes feeling supervised when working on stable and nobody 
likes doing work twice (aka backporting).

Company