[MPlayer-users] Next rc or 1.0 anyone

[Daniel Taylor]

For a structural example of the release technique described below check
out the subversion archives for Asterisk.

The Wanderer wrote:
> 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.
> 
It is a necessary step for a proper release in a project like mplayer.
It allows the developers to continue with business as usual on the main
trunk while only stability issues are addressed in the fork. The point
of it is to inconvenience as few developers as possible in the process
of making a release.

>> 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.
>
Only the ones who are interested in making the release stable, the folks
working on new features continue with the main trunk with no disruption.

>> 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.
> 
You keep saying these words, I do not think you understand what they mean.

>> 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".
>
I have a different concept of the process. Part of this could be due to
having dealt with a rather gung-ho development team in the past. A lot
of what you seem to be assuming is "extra work for the developers" is in
fact extra work for the release manager on the technical side to allow
the majority of the developers freedom to ignore the release process
completely.

> 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 only requirement on most of the developers is "don't check out the
release branch". The folks who are interested in stability issues would
have some extra work in forward porting patches from Release to Trunk.
They already have those issues right now, but without the convenience of
 a version-controlled archive of the last release.

-- 
Daniel Taylor          VP Operations            Vocal Laboratories, Inc.
dtaylor at vocalabs.com   http://www.vocalabs.com/        (952)941-6580x203

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20080630/69253d84/attachment.pgp>