[MPlayer-users] Next rc or 1.0 anyone

[Raimund Berger]

Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> writes:

> On Sat, Jun 28, 2008 at 01:38:04PM +0200, Raimund Berger wrote:
>> Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> writes:
>> 
>> > IMO: making a release tarball, getting some people to do binary
>> > builds/packages (it might be a good idea to latch onto the "releases"
>> > gentoo does), get some people to test it, especially compilation on
>> > diverse hardware and OS and if there are no obvious problems release it
>> > "officially" - if there are issues decide how important they are and bug
>> > someone to fix them.
>> 
>> Add an own rc branch/tree to the picture over which the release
>> manager has exclusive control especially during a feature freeze phase
>> during which he snapshots release candidates over a let's say 2 month
>> pre release testing period, and things begin to resemble common
>> practice.
>
> That would already be the "our release manager is rich enough to not
> need a job besides being release manager" stage. Not that I would mind
> it.


I just made explicit what has to be done anyway, but you wouldn't
mention (and likely not even think of).

Imagine your release manager putting up a "release tarball" for
testing. As it get's tested, bugs are discovered and are to be fixed
for a possible release. Where do you suppose is that gonna happen?

In the dev tree, where in the meantime there has been a constant
influx of new patches possibly introducing new bugs? In the "release
tarball", which the "manager" has lying around somewhere on his hard
disk and to which he applies patches emailed to him by developers?

Above, I just lined out common procedures for problems often not
mentioned, but which in real life usually turn out to eat the most
time and energy if not properly organized. So in reality, it's less
time and work.

Clear enough?