[gst-devel] Doing new releases

Thomas Vander Stichele thomas at apestaart.org
Wed Aug 20 10:13:04 CEST 2003


On Wed, 2003-08-13 at 16:21, in7y118 at public.uni-hamburg.de wrote:
> 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.

Some are, some aren't.  I am.  It just doesn't need that much work.  I
think you shouldn't generalize on this aspect.   It seems true though
that we aren't gaining as many developers as we would want in general.

>  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)

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.


> 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.

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.

> So I think the stable branch is pretty much dead from a development standpoint. 

The death of the stable branch is greatly exaggerated :)

> Did anybody even bother adding useful error messages to gst_element_error yet?
bother yes, finish no.  It's not as easy as has been said.  It would
help tremendously if someone actually hacked on it, and sent a detailed
plan to the list to follow.  This could just as well be tried on the
head branch.  So I attribute the lack of this being done to all of our
unwillingness to do it, it has nothing to do with status of either
branch.


> 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.


>  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).

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.

Really, I think blaming this on having a semi-closed stable branch is a
strawman's argument.  A lot of fixes for real bugs in 0.6.2 can be
worked on in head and from there easily backported.  The REAL problem is
a) developer unwillingness to work on stable because head is more fun
b) for people like me, fishing out the actual bug fixes from the "cool
system rewrite of the day", which probably makes it harder to backport
ALSA, for example.

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

Does that mean we're losing focus ? Maybe.  In any case, I see no point
in ever doing an 0.8 branch unless it adds some support for user-visible
improvements.


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.

There are even historic precedents for this :) I remember Erik doing
large chunks of rewrites on a different branch, back in the day, long
before I even knew what branches were and they confused the hell out of
me.

Thoughts ? Opinions ?

Wim, Erik, where art thou ? :)

Thomas

Dave/Dina : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
I may be qualified
for a one night stand
but I could never take the place of your man
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/





More information about the gstreamer-devel mailing list