[MPlayer-dev-eng] 0.90 release plans and others

[Arpi]

Hi,

> > 8. Leave project. (*)
> > 
> > *: not a joke. i've spent _all_ of my spare time in last 2 years on mplayer
> > development, maintaining, testing, mailing, bugfixing etc. I'll give away
> > the maintainer job after 0.90 (anyone interested? i hoped that Alex will
> > take it but nowdays he's also about leaving the project :().
> 
> I have long feared that you would eventually burn out.  Seems like it is 
> finally the case...
> 
> How about just unsubscribing from -users and doing only the fun bits of 
> MPlayer development?

Of course i'll leave all users lists, but i'll keep my eyes on -dev-eng.
And - as i wrote - i have plans on a new player, from scratch, for testing
some ideas. Maybe some code could be ported from it to main mplayer later.

But I think it serious: i _have_to_ stop maintaining of the current code.
Actually I hate to refuse so many patches just because they are ugly hacks
or (imho) useless features. Or because i don't understand that code or
because i don't have time/hw/etc to test. Users probably want them!
In the last months i felt that my maintainer work slows down development
instead of improving it. Imho mplayer needs a more free cvs policy now.

But it's only one of my reasons (this leaving project idea is not new, as
Gabu said i have it since a year, but i always decided to stay - now i won't).
The more important reason is that i'm not so interested in reviewing silly
patches (esp. that i'm unable to test most of them), fixing them and
commiting them. I want to work on more interesting things: research.
Ie. trying out new ideas of a-v sync correction, deinterlacing and so on.
Unfortunatelly the current mplayer code is so bloated - if i want to do any
bigger change somewhere, i meet tons of globals, hacks, side-effects and so
on. It's impossible to do any changes on interface, without major rewrites
and many months of bugfixing & testing following that.
So i want to drop this bloat, and restart from scratch, by reusing the good
parts (like postproc, libmpcodecs, parts of libvo/ao etc) but with a new
core and removed the hacks & useless features. I want to separate UI
(including OSD, input (key, lirc etc) handling etc) from the core.
But before starting it i need some holiday: work on non-mplayer projects.


> > IMHO mplayer is good enough now that it won't lost in /dev/null if i leave.
> 
> Probably not, but will it lose the race against xine?

imho we lose it already. see xine, its popularity started to grow since a
month and keeps growing. while we spend our expensive time by rev.
engineering codecs, optimizing code, writing demuxers, they improve the gui.
then they 'steal' the others and win. we have no chance against xine...
Ah, stability. Yes, in old days mplayer was rock solid while xine crashed at
every second click. It has been changed: mplayer is now everything but
stable (thanks to that many hacks and 10l bugs), while xine improved
stability a lot...

> > (but it really needs a new code maintainer - or maybe not: i can imagine
> > that it may work unmaintained, ie. everyone with cvs access will commit
> > everything, it will result in more unstable code, but also much faster
> > improvement/more features. or it will just go mad and turns to be unusably
> > unstable in a few weeks. who knows... see egcs vs. gcc story as example)
> 
> How did this gcc - egcs thing go?

afaik (maybe i know wrong): gcc (in early days) had very strict patch/cvs
policy (i can compare it to ours :)). later (around 2.7x) group of
developers forked code and started egcs 1.x, without these strict rules.
But it turned out that egcs is better (due to more free development) so
later they merged (2.9x). But anyway, see the future: gcc 3.x, the most
buggier (and slowest) gcc releases ever.

i see the same in mplayer & xine.
mplayer: strict cvs rules, slow development, stable code
xine: no rules at all, fast development, unstable code

so, i'll leave, it isn't question any more. i'm 1000% (not 1000l) sure.
i know that i have to stop it, now, for the above reasons.

the question is that who will take the maintainer job.
or, if no one, then will be able the project to survive.


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu