[gst-devel] queue full patch in 0.6.1?

[Benjamin Otte]

A good thing would be if people were actually allowed to commit bugfixes
to the stable branch without a bugzilla report or whatever. Because I know
I'm not really that interested to review everything I commited to HEAD to
see if it applies to the stable branch after some time again. I'd pretty
much prefer an "if you don't want this patch, move it out" policy to an
"if you want that patch, make someone put it in" policy.
That way we could
a) encourage people to try the stable cvs because it actually contains
fixes in a timely manner.
b) get more people (for example me) to put their fixes into the stable
branch.
Currently there is only a no-commits-to-stable policy and a lot of people
crying "nothing that isn't tested". That's both bad if you actually want
to have releases more often.

And you know what: People still use Linux, even though there were 2
releases in 2.4 where Linus screwed up badly.

Benjamin


 On Thu, 17 Apr 2003, Thomas Vander Stichele wrote:

> > On Thu, 17 Apr 2003, Thomas Vander Stichele wrote:
> >
> > > any patch at this point for 0.6.1 is highly controversial.
> > >
> > Actually we merged a 5 pages patch just yesterday just to allow fast
> > fast forwarding in the player.
>
> Well, what can I say ? That sounds pretty dumb from a release standpoint,
> and it basically forces us to delay the release for a week so this gets
> proper testing.
>
> I know every single one of us wants to do a quick 0.6.1 release, but to do
> proper releases you have to put your foot down at some point to get it
> out, and make sure that you have an actual code freeze at some point so
> everyone can test.  We're still learning that but the goal is to get
> better at this, not worse, with each release.
>
> The right way to solve this issue is have shorter release cycles, but not
> TOO short.  And, of course, people should start working on stuff for the
> next release right after the previous one, and not "two days after the
> first announced deadline".
>
> We have a lot to lose by putting out a release with a stupid d'oh bug just
> because some last-minute patch screwed everyhting up - we have more to
> lose than we used to, now that we have some sort of non-techie userbase.
>
>
>  Thomas
>
>  So a 5 line patch to allow buffering should
> > not be that much of a problem. Especially because I just had time to find
> > lots of brokennness in it in the last 6 hours debugging this f**king
> > GstThread element but didn't.
> >
> > Benjamin
> >
>
> --
>
> The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
> <-*- thomas (dot) apestaart (dot) org -*->
> What am I still to you ?
> Some thief who stole from you ?
> Or some fool drama queen whose chances were few
> <-*- thomas  (at) apestaart (dot) org -*->
> URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>