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

[The Wanderer]

Uoti Urpala wrote:

> On Wed, 2009-03-25 at 18:23 -0400, The Wanderer wrote:
 >
>> Uoti Urpala wrote:

>>> 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.
>> 
>> The trouble is, both moving to git and the changes you're making
>> are apparently at least somewhat controversial. Tying each one to
>> the other makes them both less likely to be accepted, not more.
> 
> The best MPlayer development repository already is in git. It cannot
> be easily ported to svn.

Then what you should be doing is to push for switching the mainline to
git, *without* simultaneously insisting that the changes you have made
in your personal fork be accepted as part of the mainline. (Once that is
accomplished, "porting" the code from one VCS to the other - a usage I
find somewhat odd, incidentally - will not be necessary.)

MPlayer has not moved to git. You may have created a personal fork which
is tracked that way, but unless there's a lot which I've missed which
wasn't discussed on these mailing lists, that does not affect MPlayer
per se.

If you want the MPlayer mainline to be in git, you need to convince
other people. Tying your acknowledgedly controversial changes to the
transition, so that accepting one means accepting the other, makes it
significantly less likely that either will be accepted. (Making arrogant
assertions to the effect that "my git tree will inevitably take over as
the mainline at some point, its superiority assures that" - which is
what I read in your initial posts on the subject in this subthread -
reduces the chances of convincing people even more.)

If nothing else, switching the mainline to git would make it easier for
other people to work with or draw from your fork, without having to jump
through the hoops you describe for porting the code from git to SVN.

>> If you want either one to happen, you should not be pushing to have
>> the other one happen as part and parcel of the same move. Get
>> either accepted first,
> 
> That is not a practical alternative.

I don't see why not.

> And even if it somehow were I doubt there would be consensus for
> either part alone.

If this is the case, then so be it. There's nothing that says that
either of the changes *has* to be made.

Setting up a competing fork, and then pretending that it *isn't*
competing and that development will eventually transition over to it
simply because it is inherently superior, seems to me to be arrogant to
the point of being offensive - and it seems to me that that is exactly
what you have done here. There's nothing wrong with a personal fork of
the code, but the attitude I see in the assumption that your fork will
become the mainline and in comments like "some old developers ... try to
keep maintaining ... [in] SVN" rubs me very much the wrong way.

-- 
       The Wanderer may be opening a can of worms...

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.