[MPlayer-users] Next rc or 1.0 anyone

[Daniel Taylor]

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.

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


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

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

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.

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

-- 
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/4ac7083c/attachment.pgp>