[MPlayer-users] Next rc or 1.0 anyone

[The Wanderer]

Out of curiosity: what happened in your reply which led to weird
line-breaking in the quotes (apparently at a hard column limit), encoded
=20 'space' characters in some places, and a similarly encoded =3D
'equals' character in one place? I have removed the misdisplayed
characters and fixed the quoting in this response, but I'm still curious
what caused the problem in the first place.


Daniel Taylor wrote:

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

I don't actually disagree with that in the slightest. The set of
currently active developers does, however, constitute the group of
people who must be persuaded to agree with this for it to go forwards at
all.

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

Fair enough.

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

Acknowledged.

I did recognize the Princess Bride reference; I've seen such many times
before, and even made them myself on occasion. The difference is that
usually when I've seen it referenced, the person making the reference
really *did* intend the obvious meaning, not just to point out the
repetition (which in this case was intentional).

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

I haven't estimated that number at all. It may well be significant.
Since they are not currently MPlayer developers, however, they are not
among the people who have to be convinced to accept this.

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

That may well be the case; I am intentionally not taking a position one
way or the other on that point. It does not at all fit with my
understanding if what the statement you made would mean.

> Among other things, it would not require that new feature development
> be halted during the release process.

Technically speaking neither does the historical process, it just
requires that such development take place on developers' own machines
and then be committed after the release. Your point remains valid, though.

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

The only question is whether it would be effectively *possible* for such
a person to do "enough" of the work to satisfy the developers who do not
like releases, which based on what I've seen seems to be a significant
fraction of them. You seem to think that it would; I have no evidence to
refute that. I am not, however, personally convinced.

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

Yes, I know that. I am saying that there are developers, including I
think at least one reasonably active one, who will use that fact as an
argument in favor of never making formal releases at all. (In fact I
seem to recall this having happened on at least one occasion.)

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

...but since any patches they might submit will be rejected unless they
are made (or, at least, apply cleanly without modification) against the
latest development codebase, I'm not sure what good attracting such
developers would do...

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

Well... what constitutes "support" in this context?

The obvious answers, to me, are "questions about using the program will
be answered" and "if bugs are found, fixes will be provided". The former
is already provided to a limited extent for older release versions,
though less so in cases where the features have changed in newer code;
the latter is explicitly not provided at all, and almost certainly will
not be, because all fixes go against the latest development version (and
because providing bug-fix support for release versions would mean that
already-fixed bugs would be reported over and over, which admittedly
happens anyway).

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