Re: [xine-devel] xine development process [was: xine and post plugin segfault.]

[Michael R. <mr...@us...>]

Hi guenter, Hi Miguel,

> > > in short, without strict management i think stable branching will
> > > do more harm than good. imho we have an excelent core to develop
> > > upon, we should focus on bugfixes and making stable releases from
> > > cvs HEAD.
> >
> > I agree with Miguel here. If the problem is fixed in cvs now, I
> > strongly suggest we keep our current practice, since we are all
> > used to it. Short intermittant cvs breakage should not be such a
> > big problem and bigger changes are always discussed extensively on
> > the list first. I think this is a quite developer-friendly
> > strategy. No need to pay attention to multiple verstions.
>
> oh - actually i understood miguels proposal quite differently, i
> though he was suggesting branching away several developement
> branches. if it just means "stick to the old practice" i'm all for
> it, however i am not sure if release managers are happy with this
> aproach because i think it can become pretty difficult and
> frustrating getting 1.0 out of the door

Uohm, well, maybe I understood Miguel wrong in the details, but it's 
still my opinion that too much branching causes too much confusion and 
we all seem to agree on that.

For the 1.0, since the TV mode seems to be getting in shape (I just 
conclude that from the cvslog, since I cannot test it.) we seem to have 
all critical features in place soon. So when documentation is updated 
and all the polishing completed, it should be possible to launch a 
release candidate. When this time has come, we can discuss again how to 
continue from there.

Michael

-- 
"Writing in C or C++ is like running a chain saw with all the safety
 guards removed."
	-Bob Gray