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

[Clemens Wächter]

On Mon, 20 Jan 2003 12:54:01 +0100
Arpi <arpi at thot.banki.hu> wrote:

> 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 :().

Pitty. Really. But I understand you fully. 

> > 
> > 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.

You do that for recreation? Hehe... ok...

I agree that the code would need a real clean-up but I think restarting
from scratch is overdoing things. How about releasing mplayer as version
1.0 and redesigning it for a 2.0? Anyways its your choice. Either way I
will approve your decision. 

> 
> 
> > > 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...

Well err... I think that you cannot fully compare xine and mplayer. They do
the same thing (play movies) but with different structures and approaches.
I really like the non-gui approach of mplayer (I don't like guis very much)
And I tested xine again (not in the last month but not so much before that)
but it doesn't simply play as much as mplayer does. 

> 
> > > (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 think mplayer needs a maintainer. Really. But I would try the same approach
as they did for the kernel development - use two different cvs trees and then
create a stable and a hacker mplayer - the stable one for a rock solid and
nice code and the hacker one for quick improvements and cvs access for more
developers. I think this would server both ideas. 

> 
> 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.

It would really be a loss for the community if it died imho. Mplayer has
some featured I'd miss ( console playing ability, commandline-interface,
codec support and most of all: mencoder). As for mencoder I think its
like a jewel - the fastest and most complete recoding program I know. 

So I would suggest to split the development in more or less independent
modules - codecs part, video out part, mencoder part, (possible video
editor part), demuxer part and so on. 

Just my 2 ¢

Clemens Wächter