On Wed, 2010-05-19 at 14:29 +0100, Tom Evans wrote: > 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. So you want a bug tracker where your issues can be left unfixed like on bugzilla.mplayerhq.hu? :) OK maybe a mailing list specific for git issues would have some use. Still seems like a weird reason to get "insanely angry" for... > 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 And if Reimar stops maintaining svn then the svn repo will die. In reality the svn repo is no less vulnerable to a single person quitting. > 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. I think not knowing about features they're missing is a lot more common problem for people who use svn... And what exactly do you think is the problem here anyway? If there was a committee of 20 people deciding which features they accept do you think the results would be better? > 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. A "crystal clear" example of exactly what? That git is not exactly the same as svn? I don't see how this would be an example of anything you talked about above. > If the vdpau support was in the main svn repo, then it would be under > the control of the 'mplayer project'. That's meaningless. > 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. You maintain that you consider it the "master repo" and that this is somehow significant, but are unable to provide any arguments whatsoever in support of that. I think trying to argue this with you is pointless if you just keep repeating "it's important!" without anything to connect it to reality. > > 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? So apparently you didn't understand the explanation. And instead of asking for more information about the parts that remained unclear to you, you decided that you just know better what's practical and what is not, despite your obvious ignorance about the subject. The git repo contains a lot of improvements over svn. The svn repo contains little that would be missing from git. To a first-degree approximation the complete merge of the svn and git repos is the git repo unchanged. You can achieve that result by just dropping svn. Getting the same end result by moving features over bit by bit from git to svn until svn equals git is obviously a huge waste of work (and even if someone wanted to do that for whatever perverse reason it would be a _lot_ of work). If you want a somewhat tweaked end result, a much more efficient way is to start from the git repo and modify that. > >> 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. No, you do not "have to". That's the first thing I explained in the message you're replying to... Did you actually read it before replying? > 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. It's not possible to have a single configure step followed by a single compilation step in the build repo, because MPlayer's configure must be run after the used libraries have been configured, built and installed in their temporary locations. As I already tried to explain once, you do not have to use the mplayer-build repo. You can configure and then compile first any possible missing dependencies and then MPlayer itself in a perfectly traditional way. The mplayer-build repo is meant to automate things more than that, and for most users it seems to do its job. > >> 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, You've been saying various things. I doubt it confirms all of them. > 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. I've seen no indication that Reimar would be willing to work on the git repo. I certainly haven't refused any work from him. And as explained above trying to backport things from git to svn would mean a huge amount of wasted work.
