[MPlayer-users] Next rc or 1.0 anyone

[Raimund Berger]

Nico Sabbi <Nicola.Sabbi at poste.it> writes:

> On Friday 27 June 2008 10:57:23 RC wrote:
>> On Fri, 27 Jun 2008 10:16:38 +0200
>
>>
>> Grabbing an SVN snapshot is far too much of a crapshoot.  The code
>> is in an unknown state of flux, and very often will not compile for
>> days on end. 
>
> very often and for days? We always pay much attention not to break
> compilation, and as fas as I can tell we succeeded

Just to be sure, breaking compilation is the best case. The
worse/worst is some non obvious issue creeping in which makes you
spend days/weeks of CPU time producing sub optimal encodings, because
you don't have the time to thoroughly test each SVN snapshot for an
arbitrary amount of time, until some dude finds out and produces a
patch, which on the way of being applied introduces some other non
obvious issue.

If you think releases are bad you clearly lack the sense for
responsibility and the discipline for serious software
development. This stuff - and especially some basic quality control,
testing and release management - may be just foolish toying around for
you, but it could well mean a lot more to others who spend serious
time, even just as users, on mplayer and possibly carelessly
introduced, random issues.

That said, and it may have escaped you, mplayer is dead anyway, at
least as an encoding application. Just follow the dev list for a while
to understand that there's no real team standing behind this being
focussed on common goals, and especially nobody who would want to make
the major effort and take that seriously crippled avi centric
architecture to the next level.

By now, mplayer (or rather mencoder) seems to be just a bunch of hacks
which had been piling up for years especially to make avi work with
modern encoding and container formats. Of course, this leads nowhere
and I guess the point of non maintainability has been reached time
ago, which at least makes the frustration among devs a little more
understandable. The lack of proper release management and taking
contributors into responsibility is - surely to a major part - to
blame for this situation.