[MPlayer-users] Next rc or 1.0 anyone

[The Wanderer]

Daniel Taylor wrote:

> 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.

I am not necessarily disagreeing with that.

I am saying that the developers are not necessarily likely to agree to
do it anyway.

>>> 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.

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.

>>> 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.

I do not know why you would think that.

I am making predictions based on observations of the developers on these
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...

>>> 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:

<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.

...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, or
you and I have completely different ideas of what the historical release
process has been.

You have described *a* release process. It is not one which has been
used (here, by these people) in the past; it is therefore an "ideal"
process (albeit not necessarily *the* ideal), something to be considered
a goal but not necessarily something which can be implemented.

I have described *a different* release process. It is - or, at least, I
have tried to make it - one which *has* been used (here, by these
people) in the past; it is therefore a "real" process, something which
may not be especially good but something which it is known *can* be
practically implemented.

I am not saying that the historical release process I described is
particularly desirable, nor that there are not better ones, nor even
necessarily that the one you described is not a better one.

Attempting to impose an outside approach, when even the status-quo
approach of "no releases at all" seems to have been doing just fine for
the developers themselves (even if it has not been doing so well for
people outside of the development team), is likely to run into problems.
Instead of starting from a goal and trying to pull (or push) people
there, it might make more sense to start from what has already been
successfully done and try to improve things; the end result (much less
the intermediary steps) may not be as good as could have been the case,
but it is much more likely to actually get done, rather than piling up
work and then never going anywhere.

> 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.

And that's good, if it can be implemented that way. I am not necessarily
persuaded that it can. I am also not certain that allowing "the majority
of" the developers to ignore the release process would be enough; it
might be necessary to allow *all* of them to do that. The present
approach, of making no releases at all, does so allow.

>> 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".

Again, "most" is not "all"; it requires that there be some (probably,
"oome sufficient number of") developers who *would* do the additional
work. This also assumes that the developers would be willing to
countenance a release branch in the first place, but I acknowledge that
that might be the case.

> 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.

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 that
there are developers who would consider that a strong reason not to make
releases at all. 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.

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 be
sent in against the latest SVN version in any case. If they *are* on the
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.

-- 
       The Wanderer

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

Secrecy is the beginning of tyranny.