[MPlayer-users] Next rc or 1.0 anyone

[Daniel Taylor]

>>>
>>>> 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.
>=20
> I am not necessarily disagreeing with that.
>=20
> I am saying that the developers are not necessarily likely to agree to
> do it anyway.
>
The set of currently active developers !=3D the entire set of developers
interested in working on the project. I think this may be the primary
point where we disagree.

>>>> 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.
>=20
> And if "the ones who are interested in making the release stable"
> consists of "none of them"? Given the prevalence of the attitude that
> "releases are unnecessary and/or a fundamentally bad idea", I am not at=

> all sure that that would not be the case.
>=20
Then the release manager's job includes developer. This guarantees at
least one person looking at the release version with an eye exclusively
to stability and security. The fewer people doing this, the longer the
process takes, but that's life.

>>>> 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.
>=20
> I do not know why you would think that.
>=20
> I am making predictions based on observations of the developers on thes=
e
> mailing lists over the course of several years. My predictions may be
> wrong; that does not remotely imply that I do not understand what I am
> saying. In point of fact, I find the implication that they do to be
> mildly offensive...
>
My apologies for the offense, I have an unfortunate tendency to misquote
"The Princess Bride" on occasion. It was meant as a mild dig at your
consistent use of "unlikely to happen", not as a critique of your
knowledge of the language.

 I think you underestimate the number of programmers that use MPlayer
but aren't interested in diving in to a constantly changing codebase
when they run into problems.


[snip]
>>> 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.
>=20
> ...the only thing I can easily take away from your saying this at this
> point is that either you have missed what I am trying to do/say here, o=
r
> you and I have completely different ideas of what the historical releas=
e
> process has been.
>=20
I understood what you said of the past release process. I just happen to
think that the release process I propose would have many advantages over
what you described. Among other things, it would not require that new
feature development be halted during the release process.

On the gripping hand: if the project gets a release manager then that
person is the one who will be doing the work on the release.

[snip]

> If the existence of an "official" release version would encourage
> third-party coders to create patches and fixes against that rather than=

> against the development version, then I can say with some assurance tha=
t
> there are developers who would consider that a strong reason not to mak=
e
> releases at all.=20

As soon as you make a tarball and say "This is a release" people will be
making patches against it. This is an inevitability. If the release is
in version control then it is possible to make use of these patches and
track them.

> Likewise, if a released version would need to be given
> support and maintenance (beyond very limited backporting of major
> security fixes), that would also be considered a significant reason not=

> to release.
>=20
Part of the point of a release is that it changes as little as possible.
I would hope that any security-only patches would be back and forward
ported freely to the extent they apply. Forward porting security patches
is not uncommonly done by the release manager, especially after the
first month or so when all the mainline developers have lost interest in
the release branch.

> If the "folks who are interested in stability issues" you mention are
> not on the development team, then I don't know if I see how the
> existence of a fixed version to base the "unported" patches on would
> help or hinder the process of porting them; the patches would have to b=
e
> sent in against the latest SVN version in any case. If they *are* on th=
e
> development team, I can see how it might make some difference, but it
> looks to me more like a "sideways" change - a different kind of
> difficulty, but not a different degree.
>=20
The important bit is having the release branch in version control so
that it is supportable. Having such an archive will draw developers who
are more interested in working on a relatively static codebase (I.E.
programmers who use MPlayer but who have other projects demanding the
majority of their focus).

Right now there is no supported release of MPlayer, and that is a
situation that is quite unfortunate, but can be changed.

--=20
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/5be4c740/attachment.pgp>