Re: [gst-devel] New policy needed for 0.6.1

[Thomas V. S. <th...@ur...>]

> > > Any objections?
> > 
> > Yes, of course.  First of all, whether or not we are doing a 0.6.1 release 
> > has nothing to do with the two branches.
> It very much has to, cause it creates an additional job of reviewing patches to put onto 
> the branch.

No it hasn't.   The ONLY reason we haven't done a 0.6.1 release is because 
nobody has had time to do the proper testing and the releasing.  Whether 
that release is made from the HEAD or 0.6 branch is pretty much 
irrelevant.

> > Second, doing a 0.6.1 off of HEAD would be crazy - no way in hell are we 
> > able to ensure, with our current testing, that it is even remotely 
> > functionally compatible with 0.6.0
> We would be able to ensure that nautilus-media and gnome-media continues to work,
> and that is what GNOME needs from us.

No, we won't be able to ensure that.  If I have to convince you that our 
user base has drastically changed and will do even more so in the nearby 
future, then something is wrong.

If we *all* don't realize that our user base has changed from a few 
thousand to a few hundred thousand and will reach a million very soon when 
RHL9 comes out next week, and we need to adjust our policies and release 
practices accordingly, then something is wrong.

If you think reviewing a couple of simple patches and committing them to a 
branch is hard, wait until you get a few hundred mails telling you your 
software sucks because a million people use it.

We're not in kindergarten anymore :)

> > The only thing that needs to be done is simply review Ronald's and 
> > Benjamin's mails, apply patch by patch what they suggested if nobody was 
> > against them, and add EACH bug number + link to patch to the changelog so 
> > that it is CRYSTAL CLEAR what we fixed in this branch.
> No, Ronalds and Benjamins lists are a good start, but there are other patches we want 
> into the branch too.

If there are, then they should be proposed and reviewed.

> Well this is why I feel the branching is bad, it adds a lot of extra work which 
> someone has to do, and when nobody has time and/or want to do that extra
> work we don't get new releases made.

We *knew* this beforehand.  We can't just say "oh, we really didn't want 
to do that work, let's make a big mess again".

Also, there is no real need for a *STABLE* release at this point, because 
0.6.0 is pretty good.  There is also no real need to CRAM 0.6.1 full of 
new stuff, because it was a feature-stable branch by definition and only 
needs bug fixes.

If you want to push ahead, make an unstable release - a 0.7.1, which is 
very much like the "oldschool" releases you want to make, and which WON'T 
go into gnome at this point.


> > But really, doing a release from HEAD is the insanest thing to do at this 
> > point.
> Why it worked well enough up to 0.6 so I don't see why we would have bigger problems now.

The worst argument you could have hoped to make for the case.  I disagree 
100% completely - it used to work is simply not good enough.
(It's also very untrue as I spent time in the past backporting stuff and 
adding compat headers because of API breakage)

> And as for API breakage issues, well I do not know of any work being
> done atm which would cause significant API breakage, and no API breaking
> work that has a huge impact on gnome-media and nautilus-media.

On the contrary - you were there on IRC when Wim told me that one API fix 
would break media-info, which is in nautilus-media.  So we can't afford 
that API change at all at this point in 0.6 branch.

And besides, we already said that 0.6 would have NO ABI/API changes, and I 
see no reason to not stick to that.


Let's face it here - we're just not doing the work, and we're not 
discussing this stuff on IRC enough anymore, because we're not all there 
all the time anymore for some reason.

I know I still am all through the week at work and follow discussions, and 
I've seen you being there less and less at those times.  And you've 
probably seen me less there on weekends.

But that doesn't mean we have to start acting like kids, bickering about 
decisions already made and not doing the right thing.

So, whatever happens, the conclusion is very simple:

0.6 branch will have NO API CHANGES because we committed to that before
0.6 branch will ONLY have well-prepared and reviewed (by at least 1 
    other code person) patches

0.7 branch can do whatever we want to do (within limits of sanity)

What you're pushing for, Christian, is an ASAP release, while you have to 
ask yourself if that in itself is a useful goal and you also have to ask 
yourself if it's a good idea to be fixing the symptoms instead of treating 
the "disease".

My opinion is we should fix the disease and work out how we are supposed 
to achieve the quality we committed ourselves to, not the other way 
around.

Thomas

 -- 

The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
And I know
they all look so good from a distance
but I tell you I'm the one
<-*- thomas  (at) apestaart (dot) org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/