[MPlayer-dev-eng] release... WHEN?

[Anders Johansson]

Hi,

> Hi,
> 
> > >From what I can understand after having read the two docuents above is
> > that to keep MPlayer growing in it's current speed (is that
> > desirable?) one needs either enforce more strict release control or
> > split the project into smaller parts.
> > 
> > If that isn't done the quality of the releases will decrease, which
> > will lead to less users and thereby less bug reports and patches. This
> 
> yes i know all this, and also was thinking about branching, or its
> simplified way: making -rc versions of releases, and continure development
> in cvs, then backport bugfixes to the -rc and finally release.
> something like the kernel development.
> you can reach it with manual patching, branching, or duplicating cvs
> repository (this is why the main tree is called 'main' not 'mplayer')
> 
> but
> - the project is not so big yet

When I said big I compared it with the core of Apache.

> - we have only a few "full-time" developers
> - no one has time nor interest to backport fixes :)

Could it somehow be automated (at least partly)?

> > Personally I would be very happy if the project was split in small
> > parts the following way:
> > 
> > 1. Throw out the GUI.
> > 2. Remove all commandline parameters except --help, --version and
> > 3. Write a unified hirarcic control and configuration library.
> > 4. Throw out the playlist and runtime control (i.e lirc, mouse and
> >    keyboard) and control the player kernel through a socket or shared
> >    ram using the config language described above.
> > 5. Use an external program for reading and writing the config file
> >    and send the config parameters to the player kernel according to
> >    4. (alsa does this, very nice).
> 
> ROTFL :)))))))))))))
> remove all code, and no bugs left :)
> 
> do you really believe that gui or config/playtree code cause the
> bugs we have???

No, but I think all that functionality makes mplayer harder to debug
and also harder to understand for someone who isn't familiar with the
code (i.e. our users), so my guess is that the source was more modular
 - then we would get more and better bug reports. I also think the
above suggestions would make mplayer easier to run under other
applications, which would expose it to more "developer eyes".

> 
> > But who am I to say (i.e. sorry for pissing everyone off :).
> i wanted to ask...
> 

I know the changes I suggest are huge an I am not willing to write it
myself, but I had the idea, so I thought I shoud share it, and I am
willing to help implementing it into the part of the player that I am
familiar with.

> 
> A'rpi / Astral & ESP-team
> 

//Anders