[MPlayer-users] Next rc or 1.0 anyone

[The Wanderer]

Daniel Taylor wrote:

> The Wanderer wrote:
> 
>> 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.
>> 
> So am I, it happened during transmission somewhere and broke my
> signature as well.

In hindsight, it also appears to have removed the attribution lines; I
usually add those back, but found it too much bother last time. As long
as it doesn't happen again, though, it's probably not worth more than
being curious about.

>> Daniel Taylor wrote:
> 
> [snip] I understand your concern about selling the concept to the
> existing developers. The vast majority of the active developers need
> to at least accept any release process or it would cause unnecessary
> hard feelings among the team.

Agreed.

I'm no longer positive, but I think this is the major point I've been
trying to get at (in some respect or another) since my first response.

>>> 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...
> 
> In the case of having an actual production release it provides a
> semi-stationary target. If Joe Programmer discovers a problem, spends
> a couple weeks chasing it down and diagnosing it, a couple more weeks
> fixing it and then submits a patch, it is reassuring to him to know
> that it won't be rejected out of hand because a developer added a
> function to the file his fix is in while he was producing it.

But it very possibly *will* be so rejected, unless more than just the
release practices are changed. As I said, the rule is that any patches
should be submitted (and must in any case apply without modifications)
against the latest development code; if a patch is submitted against the
source to the released version, the submitter will almost invariably be
told "re-send this against the latest version", and if the underlying
code has changed in the meantime that's their problem.

You might think that that's also a problem which would need changing,
and you might be right, but it is not related to the methods employed
for making releases and so is not something which would be affected by
changing that.


(My eyes and proofreading habits are starting to trick me... I have
three times now had to remind myself that no, it would *not* be
correctly spelled "semi-stationery"...)

>>> 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).
> 
> When bugs are fixed in released versions most projects trigger an
> update release fairly promptly. The update then propagates to all the
> distributions (some faster than others...) and bug reports about
> that particular bug go away. Right now this project has no mechanism
> in place to do that.

I have some impression that it can happen that bugs are fixed (or new
features which fix "it doesn't work" situations introduced) on a
sufficiently frequent basis that this would not necessarily be
practical, but I am not positive that this is in fact considered to be
the case.

> If the developers really want to go with "head of trunk is current
> release", then a build server should be set up to generate packages
> for the main targets and keep those up on the main download page
> instead of the largely unsupported rc2 that's up there now. I believe
> Wine set a good precedent for that, and it was fairly well accepted
> by the distributions and the end users on that basis for quite a
> while.

If this can be made practical and automated, in a way clean enough to
get the buy-in of the people who do design work on such things around
this project, then I think it would be a very good and quite possibly
viable idea. Some provision would need to be made for what happens in
case of build failure, or build failure for one platform but not for
another, but that might not be impossible.

> Part of the current problem with support on the -users list is that
> having 1.0rc2 as the pre-compiled download on the main MPlayer page
> sets an expectation that it is supported, with both configuration and
> bug-fixes. When that expectation is not met, people tend to get
> upset.

I acknowledge that this does seem a reasonable expectation. At bare
minimum, warning on the Website and probably in the documentation that
"the latest release version is only considered supported for X time
after it comes out" (where the time period in question would probably be
about two to four months) would be appropriate. Of course, an approach
which lets people (more) easily obtain and use a version which *will* be
supported is better than that bare minimum, but I agree that the current
situation is hard to describe as reasonable.

> Honestly, I've been on a reasonably current checkout for long enough
> that I'm not sure I could answer usage questions for folks still on
> rc2.

I've been on the user lists since somewhere around the time of 0.90, and
for most purposes, it's not as hard you might think; it can get
complicated for e.g. MEncoder, or if someone is trying to do advanced or
complex things which approach the limits of the program (such as the
person who wanted to do something like run four simultaneous in-sync
playbacks of the same video on four display devices, and control them
all via the same remote control), but for most purposes the questions
people have about MPlayer itself tend to be generic enough that they are
not particularly version-specific.

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