On 23 May 2010, at 00:53, Phil Rhodes wrote: >> And compared to the level of testing these versions get anything we >> could do >> would be quite inadequate, so whatever release we would do would >> not be of particularly >> higher quality than what we do now. > > To me it isn't so much about quality as it is about a known > baseline. If someone has release (n), at least you know they have > release (n), as opposed to some frankly fairly random SVN checkout > "at some point" with a bunch of patches and fiddles applied to make > it compile and do what they want. It would get us away from this > constant request to "use latest SVN" which is not practical for most > of us. But AIUI it doesn't *matter* if the person has release (n), because if they have found a bug, it's not going to be back-ported to version (n). This would only be useful, perhaps, if there were two tiers of mplayer support lists, and in the first instance other end-users could say "I also use release (n) and I don't have the problem you describe - have you tried the --with-foo option?" However escalation to developers would still require the latest SVN version. Seems to me that the ideal answer is more developers, but we can't magic them out of thin air. It seems like mplayer is good enough for distros, and everyone tolerates that video will never be perfect on Linux, so there is no need for the commercial distros to contribute to mplayer or give it more love in their releases. I must be untypical, because I use Gentoo, which provides as standard provides a way to easily build SVN releases. I have never had a problem compiling for myself using `configure && make` on the rare occasions (PS3) when I have had to build manually. Stroller.