[MPlayer-users] Next rc or 1.0 anyone

[The Wanderer]

Daniel Taylor wrote:

> In my opinion generating releases for Mplayer should be as simple as
> possible.
> 
> 1. Create a fork.

To the best of my awareness, this has not been done for any previous
MPlayer release, and I would not expect the developers to be
particularly willing to do it in future.

> 2. A few of the developers and the release manager take a look
> through that fork for any obvious (or even less than obvious)
> problems. 2 weeks of this, tops.

This requires additional work on the part of the developers, beyond what
goes into ongoing development. It is therefore unlikely to happen.

> 5. Keep the tagged fork active to receive security updates submitted
> by distribution maintainers.

These updates would have to be reviewed and/or possibly merged, and as
such would also require additional work on the part of the developers.
It is therefore unlikely to happen.

> So yes, at the risk of being considered a volunteer, Mplayer does
> need a release manager.

I think the various people who have used that term in this discussion do
not all have the same idea of what "release manager" means, or what one
would do...


In the past, according to what I have observed, the MPlayer release
process has been something along the lines of:

* Decide "Okay, we should do a release fairly soon", and get enough of
the developers to agree to go along with that (the latter being much the
harder task).

* By the cooperation of all developers, hold off on allowing anything
with the risk of breaking something to be committed - though
theoretically this applies at all times, the criteria used with a
pending release have been somewhat more narrow.

* Ensure that the changelog and (to the extent possible) the
documentation are up to date.

* After a week or three like this, make a source tarball of the current
most-recent SVN revision and pass that out to the people who build the
'official' binaries.

* Put up the tarball and the binaries, and announce the release on the
Website.


The vast majority of the work in this process - including, in the first
step, persuading developers to go along with slowing things down long
enough for a release - has historically been done primarily (if not
exclusively) by Diego Biurrun; it is also what would be expected to be
done by a hypothetical "release manager".

With the exception of agreeing to the first step and cooperating (by
*not* doing things) in the second, no part of the historical process
requires any work on the part of the developers. I do not think it
likely that the developers would agree to any release process which
requires them to devote time and attention to something outside of
continuing development. The process you outlined would require that; I
therefore doubt that it would be considered acceptable.

-- 
       The Wanderer may not be helping in the slightest

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.