[gst-devel] Doing new releases

[in7y118 at public.uni-hamburg.de]

Quoting Thomas Vander Stichele <thomas at apestaart.org>:

> You are if you go through the motions of covering everything.  I'm just
> guessing nobody feels up to the whole "make patch, test it, file a
> bugzilla entry, milestone it for next 0.6 release, check out anonymous
> copy, do good build/distcheck test, commit it, close bugzilla report"
> cycle.  I can understand that, but it's not true for everyone.  I for
> one am happy to go through these whenever I have time and there are
> patches ready.
> 
I think the number of people working on stable is too small. I know that you, 
Ronald and Julien are working on the stable branch, but it's only bugfixes for 
bugs that someone filed in bugzilla.

> If somebody cared about alsa in the stable branch and could work on it,
> it would happen.  As it is, none of you who use alsa are willing to work
> on the stable branch, and people like me who are don't have alsa.
> 
Alsa was just an example. The same goes for ffmpeg, qtdemux and all the other 
plugins I think.

> > 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.
> 
> :-) which was what I suggested for 0.6, but people wanted 0.7 head
> branch ASAP.
> 
So I'll just assume we'll do this with 0.8 unless someone speaks up.

> I think it's a good idea that the "standards" of working on stable
> branch are high.  I think you forget that the effective userbase of
> stable vs head is orders of magnitude higher.  Our commiting and
> always-build-and-work-quality standards should be comparatively higher
> as well.
> 
Considering that HEAD almost always builds (even after the large changes that 
were debugging and caps redoing) and the fact that nearly everyone recommends 
HEAD from cvs when people have problems with stable are an attribute of our 
high standards.
In fact I'd trust everyone of our developers to work directly in stable cvs. 
There is certainly enough review for all commits from people reading the -cvs 
list.
YMMV, but I would not be afraid to open stable up to everyone, especially if 
there were some rules in place of what you should not do in a stable branch.

> What's even more worrisome is that there is not really a good reason to
> start doing 0.8 anytime soon at all.  The more important things we
> should be working on, like support for DVD, rework of event system, ...
> (ie, all the reasons we thought we needed a 0.7 branch for :)) has been
> largely untouched.  The debug rewrite looks good, and other things look
> good to, but ultimately they have very little effect on our stated goals
> for 0.7.x
> 
I think you're looking at it the wrong way. The features that have been put in 
place are a solid foundation for changes that we wanted to do. And they 
certainly are user visible- Debugging is available to apps and plugins in HEAD 
(they only need to start using it ;)) - I did this only because Rhythmbox 
debugging sucks compared to GStreamer and I wanted a good debugging system 
there. The caps rewrite allows better colorspace conversions and MPEG4 
integration - which means more supported video formats.
The next thing you'll see from me is tagging which will be very visible for 
Rhythmbox. Actually all my work in HEAD is directly geard towards the 
development of Rhythmbox as my primary goal right now is to get a Music Player 
into GNOME that is based on GStreamer to get more users using our lib. 
Currently we're losing too many bug reporters to xine.
Oh, and Ronald is doing gst-rec and providing working muxers. That's quite user-
visible, too.

> As for the future, I think that
> a) when we make a stable branch for 0.8, HEAD should be at first
> ACTIVELY used for testing fixes for 0.8 issues so they can be easily
> backported
> b) invasive changes (coding style, system rewrites, ...) should be done
> on a different branch entirely, because they stifle backporting from
> head to stable
> c) if we do this, at some point during the devel cycle it will be easy
> to do a merge from REWRITE branches to HEAD, since they won't grow out
> of sync.
> 
Developing in different branches is bad for 2 reasons:
1) Nobody really cares about it unless it's in an important branch. And I hate 
writing code that nobody cares about. Nothing is more demotivating than that. 
The last time I had that problem I stopped coding for almost a year. (GstData 
rewrite)
2) Branching support in CVS is horrible. That's why I always use a HEAD 
checkout and post patches to the list.
I'm gonna present a theorem that I think is important: "Nobody likes to do 
porting." I'll assume this holds based on people's behaviour. If not, please 
tell me. And because this is the case it should IMO be avoided if at all 
possible. Concluding from that the development of code should be done in the 
branch it's supposed to end in.
This would mean that we need to find a way to allow development in the stable 
branch - not any development, but the development we want to end there.


Another thing occured to me while reading this mail:
People might actually have done stuff that's interesting for stable, if they 
hadn't had the HEAD branch to hack on. So if we hadn't opened HEAD that early 
we might now be there with the old caps types but with working muxers, without 
new debugging, but with well working subtitling support.

I still vote for longer keeping the stable branch be the same as HEAD and 
keeping it more open, too.


Benjamin