[gst-devel] cvs use

[Benjamin Otte]

If this leads to anything that slows down development, I'm totally against
it. If we get policies in HEAD like the ones we have in STABLE, that is
just stupid.
What I want right now is accelerated development because there is a
timeline to match.
The only thing to get this accelerated development and ironed out bugs is
to get our ideas out to the people. If everyone develops in his own branch
nobody tests his stuff. That sucks.
What we need is us actively using GStreamer and all the latest patches
that break stuff _right now_, not when they might be stable.
You probably don't know it, but from end of July to mid-September spider
did not work, unreffing was segfaulting with a 50% chance and there was
another blocker in the code.
It was perfectly well compilable though.

People only find bugs when they use code. And when more people use code,
more bugs are found.
So there's 2 things needed:
1) get your code into cvs HEAD.
2) use cvs HEAD as your main media framewrok (as I am apparently the only
one doing because all you sissies run Rb with stable or you would have
found those grave bugs in those 2 month (!) we had them.

If anybody policies committing to HEAD, there must be a _very_ good
reason. "It compiles with less errors" is the wrong reason, because it
guarantees nothing.

I don't want to spend 5 hours of my holidays fixing age-old bugs that are
only in the code because noone uses it. I'll happily fix new bugs though
that are introduced by new code.

Benjamin

PS: I'm going to merge tags directly into HEAD btw. Especially because it
breaks nothing at all and just extends functionality.



On Mon, 3 Nov 2003, Thomas Vander Stichele wrote:

> Hey guys,
>
> I'm sending this mail because I'm starting to feel the current way of
> and rate of committing to CVS is scaring me senseless.  In the past we
> used to have a pretty healthy habit of mailing the list in advance,
> warning them of changes about to happen, why we need them, what they
> solve, and some sort of "random" design document.
>
> Right now, people are only discussing some stuff on IRC at best,
> committing, breaking the build for days, implementing new stuff while
> the build is still broken, and so on.  There is no quality control
> whatsoever, no way to check if the changes make sense except for reading
> code, and no push towards a good design.   And all of this right when
> everyone decides we need to get into GNOME 2.6, which means we need
> everything bugfree in five months (!).
>
> I think it's time to rediscuss some of the policies we need to adopt to
> make this goal achievable. having our project spin completely out of
> control is not a good way IMO to achieve this goal.  In my mind, I'm
> hoping we can get to a better level of quality control than we used to
> have in the not-to-distant past, which included things like daily builds
> of CVS and testsuite runs, and keeping the build compilable at all
> times.  I would want to add more checks to these, like the automated
> media test, and more regression tests, and so on.  But first of all, I
> would like to know what other people think we need, because it's not
> going to work unless we manage to agree on what level of quality we want
> to achieve.
>
> So, thoughts ? Or should I just say something on IRC and then commit a
> POLICY doc to CVS, following the new commit culture ? :)
>
> Thomas
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>