[MPlayer-dev-eng] [PATCH] libbs2b audio filter

[Uoti Urpala]

On Tue, 2009-03-24 at 22:38 +0300, Andrew Savchenko wrote: 
> On Tuesday 24 March 2009 03:31, Uoti Urpala wrote:
> > On Mon, 2009-03-23 at 21:30 +0300, Andrew Savchenko wrote:
> > > > I did add something like this (in the git repo).
> > >
> > > Then why this is not added to the main svn tree? This is very
> > > good
> >
> > There's lots of such stuff in the git tree. Porting things to
> > svn would be a waste of effort; moving the rest of development
> > to the git tree is more practical.
> 
> Just curious, but is this common command decision? I haven't heard 
> about it. And if you have a lot of huge changes they will take a 
> long time to be approved by other developers.

I doubt there will ever be consensus.

> As I can see code QA 
> requirements are rather high here, this is good, but also this 
> implicates some responsibility for taking care about changes to be 
> approved.

If you're saying the changes should have been developed in a way that
everyone would've accepted, then that would have been an impossible task
as far as I can tell.

> Concerning git. If this will be an oficial decision, I'll follow.

That will probably depend on whose word you'll take as "official" :)

> But IMO git is overmuch for middle-size project like MPlayer. Git 
> suits good for large *and* distributed projects like kernel, but 
> for smaller tasks in may produce nothing but overhead. Yet again, 
> this is my private subjective point of view.

I'm not sure what you're referring to as "overhead". Anyway the code
already is in git and porting it to some other VCS would be a lot of
extra work. (And even if there had been zero controversy about the
changes being eventually desirable, some of them would still have been
better developed in a separate branch, and that would've been a lot
clumsier with svn.)

> > > that someone cares about this issue, but it should be fixed
> > > not only somewhere locally, but at the mainstream. What about
> >
> > The reason the git tree is not the "mainstream one" yet is that
> > some changes are controversial and there are developers who
> > still want to work on the svn tree.
> 
> Oh, please, do not try to fork.

If you believe you can organize the transition to the git tree without
controversy, feel free to try. I won't be holding my breath though.

> There is no good from this kind of 
> attempts, you may remember mplayer-xp (or -mp, I don't remember 
> exactly).

That there is no consensus about moving to git does not make it the same
as mplayer-xp.

> If you have some changes, you must discuss them. I'm on 
> this lists for several years (thought I'm not rather active) and I 
> can see that most people are open for discussions here. Yes, you

I've not only been on the list but also done a significant amount of
development, and I think I have a better view of what is realistic and
what is not.

> need to spend some time, yes, rules are strict, but there is no 
> other way for collaborative work and stable code simultaneously.

There are better ways. MPlayer development has had quite a lot of
problem areas that can be done better and have been done better in other
projects. And as far as I can tell trying to reach any kind of consensus
for the changes would not be a realistic alternative. It'd only waste
time in endless discussion that would never reach agreement.

> > The git tree will become "mainstream" in the future however,
> 
> I doubt it, I remember some of this kind of statements in the past, 
> but not all of them were realized.

We'll see. I believe otherwise, and I do know more about the situation.

> > and even if some old 
> > developers who dislike the new changes in git try to keep
> > maintaining a separate svn-based version it's unlikely they
> > could keep it competitive.
> 
> MPlayer, like many other OSS projects (and not only opensource) 
> somewhat lacks manpower in one degree or another. I do assume that 
> any kind of split/fork idea will bring zero to negative benefit to 
> everyone.

What would be the alternative? I do not believe trying to reach
consensus via discussion is realistic. And losing all the improvements
because of developers who resist change would not be exactly positive
either. "Doing the same development, just everybody cooperating" is not
an option. Either attempts to improve things are dropped, or things are
changed against the will of some developers.