[MPlayer-users] Next rc or 1.0 anyone

[Raimund Berger]

The Wanderer <inverseparadox at comcast.net> writes:

>> When bugs are fixed in released versions most projects trigger an
>> update release fairly promptly. The update then propagates to all the
>> distributions (some faster than others...) and bug reports about
>> that particular bug go away. Right now this project has no mechanism
>> in place to do that.
>
> I have some impression that it can happen that bugs are fixed (or new
> features which fix "it doesn't work" situations introduced) on a
> sufficiently frequent basis that this would not necessarily be
> practical, but I am not positive that this is in fact considered to be
> the case.
>
>> If the developers really want to go with "head of trunk is current
>> release", then a build server should be set up to generate packages
>> for the main targets and keep those up on the main download page
>> instead of the largely unsupported rc2 that's up there now. I believe
>> Wine set a good precedent for that, and it was fairly well accepted
>> by the distributions and the end users on that basis for quite a
>> while.
>
> If this can be made practical and automated, in a way clean enough to
> get the buy-in of the people who do design work on such things around
> this project, then I think it would be a very good and quite possibly
> viable idea. Some provision would need to be made for what happens in
> case of build failure, or build failure for one platform but not for
> another, but that might not be impossible.

Don't know if you guys are aware of it, but what you're really
fighting about (resp. against) here is svn/cvs, and the hassle it
involves to maintain a release and development branch, including
carrying patches over amongst them. That's why some of you guys so
desperately try to keep all on one branch, although it involves
various kinds of compromises.

I'm not here to advocate anything, but that's really one of the
stinkers git stepped up to solve. And regarding scm and release
practices, linux kernel development clearly became a role model thanks
to it.

So while I don't propose anything here, I do recommend keeping in mind
that at the bottom of the disagreement just lies the currently used
toolset's lacking support of proper practices. Remembering that might
help taking a little heat out of the discussion.