On Wed, May 19, 2010 at 12:55 PM, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote: > On Wed, 2010-05-19 at 10:55 +0100, Tom Evans wrote: >> As a heavy user of mplayer with vdpau, I have to use the git fork of >> mplayer to get smooth playback with vdpau. It makes me insanely angry >> that this code isn't merged back to svn, that I have to use a non >> official repo, > > Why do you care about those? Determining "officialness" is arbitrary > anyway. If everyone agreed that the git repo is official, or a copy of > its contents was committed to svn so you could get the same code from > there, would that really somehow improve things for you? > You must be arguing simply for the sake of arguing! The official repo has a website, a mailing list etc. There's a way of reporting bugs/errors. I have no clue where to raise issues about your unofficial repo. Having the working vdpau version of mplayer in a git repo managed solely by you requires that you continue to maintain and update it. If you decide to stop merging changes, nothing gets added. If theres a feature change in svn that you don't agree with, then you don't merge it, and users of your repo have no idea it has been added. A crystal clear example of this is fixed vo. In your git repo, you've made some fixes and decided that fixed vo should be the default, which is different to the stock mplayer, which leaves users of your repo confused to the behaviour they see. If the vdpau support was in the main svn repo, then it would be under the control of the 'mplayer project'. You maintain that this is the same, because there are only a few active committers, but that doesn't really matter. The svn repo is the master repo. > Trying to merge things to svn would make little sense technically; there > are too many changes in git for that, and the git tree already works. > Almost any possible problem someone could find with the current git code > would be better fixed by improving the git repo rather than by trying to > move its features to svn. > So, in your mind: svn repo is full of broken code. git repo is full of awesome code, and it is so awesomely different there is no way it can be merged back to svn. Really? > >> ?that I have to use a non standard build system that is >> built on lots of magic (autoconf + python scripts? I mean really.) > > First note that you don't have to use those parts if you don't want to. > The mplayer-build repo is an extra convenience wrapper to build ffmpeg > or ffmpeg-mt and libass. If you build or already have suitable versions > of those libraries installed on the system then you can build MPlayer > against them without ever touching the mplayer-build repo. > > Second, would there be some actual problem even if you did have to use > those scripts? They seem to work fine for most users. Apparently you > dislike them for some reason, but it's not clear whether that is based > on anything substantial. > > Also note that nothing in MPlayer or the build repo part themselves uses > autoconf; only the libass build system uses it (if you want "standard" > wouldn't autoconf be pretty much match that anyway?). And if the build > repo scripts were something like shell instead they'd be much less > robust. > Yes, I misspoke when saying 'autoconf' - I really meant 'configure + Makefiles'. I already knew how to compile mplayer. I run configure and point it at the appropriate libraries. In your system I have to use a Makefile to launch a python script which parses a config file in order to run configure. If I want to clean the build, I have to run a shell script called 'clean' rather than the universal 'make clean'. That is not good software management - inventing a build system is surprising. Good software follows POLA. > >> There is no point in having two separate repositories for this work, >> and from my point of view, it seems like it is ego rather than any >> technical issue that keeps the two separate. > > I don't see technical justification why having two repositories would be > necessary either. What I wrote about the respos earlier in > http://lists.mplayerhq.hu/pipermail/mplayer-users/2009-December/078521.html > should still be mostly valid. > That just confirms what I've been saying; no offence to either of you, I love the work both you and Reimar have done in creating the best media player around, but you both need to grow up a bit and work together IMO. What if a third party managed and triaged patches to merge the vdpau changes from the git branch? Would those get accepted? Cheers Tom
