[MPlayer-dev-eng] [POLICY] clarify conditions for functionality removal

[Diego Biurrun]

On Wed, Feb 08, 2006 at 02:44:55PM +0200, Ivan Kalvachev wrote:
> 2006/2/8, Diego Biurrun <diego at biurrun.de>:
> > On Wed, Feb 08, 2006 at 12:37:58PM +0200, Ivan Kalvachev wrote:
> > > 2006/2/8, Diego Biurrun <diego at biurrun.de>:
> > > > On Wed, Feb 08, 2006 at 10:01:18AM +0200, Ivan Kalvachev wrote:
> > > > >
> > > > > This is exactly the reason I do not want this text to be changed in it
> > > > > current form.
> > > > >
> > > > > Your text says that you can remove functions after discussion, it
> > > > > doesn't say that e.g. everybody should agree with it.
> > > >
> > > > Nonsense.  Before my change the paragraph read
> > > >
> > > >  4. Do not change behavior of the program (renaming options etc)
> > > >     without first discussing it on the mplayer-dev-eng mailing list.
> > > >
> > > > It doesn't say that everybody should agree with it either.
> > >
> > > Yes and on every release we always break at least one automated script
> > > that uses mplayer/mencoder ;)
> > >
> > > Please make difference between option, function, functionality and features.
> >
> > No, this is not about writing pages and pages of text.
> 
> WTH are you taking about?

I don't want to make the CVS guidelines a 20 page document.  I want a
few flexible rules that are augmented by common sense and tradition.

> > > > > So... please reverse it and leave it as it was. The right way is to
> > > > > say when we can remove functions based on existing precedents, not
> > > > > open huge backdoor.
> > > >
> > > > This is not a "huge backdoor", it just puts current practice (based on
> > > > existing precedents) into writing, nothing more.
> > >
> > > It is not.  Until now you could remove features only "because they
> > > were useless/shit/broken hacks" after discussion and agreement from
> > > developers.
> > > Now all you have to do is give warning.
> >
> > Nonsense.  I quote again what the paragraph said before my change:
> >
> >   4. Do not change behavior of the program (renaming options etc)
> >      without first discussing it on the mplayer-dev-eng mailing list.
> >
> > If your argument were correct, you could change program behavior before
> > just by giving a warning beforehand on dev-eng.  This has never been the
> > case.
> 
> Maybe you don't understand English?

This from you of all people..  How come the threads you participate in
have such a strong tendency to degenerate into flamefests?

> > Ivan, you are evading my main argument and the point why I made the
> > patch/commit in the first place: That I was just putting *current
> > practice* into writing.  You haven't addressed this point at all..
> 
> I did. And I said that this is not the current practice.

It *is* current practice.  No rules are set in stone.  Things are
discussed on dev-eng until a consensus is reached.

> We don't remove features unless:
> a) They are ugly hacks that bloat the code and make it hard to maintain.
> b) They are broken. They doesn't work as expected or work only in few
> cases. Probably because of a)
> c) Nobody uses them, Probably because they are obsolate and because of a),b).
> d) Nobody maintain them, nobody is interested in fixing them or
> implementing them in the right way. Probably because a),b),c).
> 
> You see alsa mmap falls in all of them, while playtree falls only in a) and d).

This does not contradict my proposal since all of this is taken into
account when the removal of features is discussed on dev-eng.

All of this is a non-issue.  The problem with the policy before my
change was that it disallowed removing features completely.  This is
just not current practice.  We have removed the CPU speed measurement,
we will probably remove mmap from ao_alsa, both without replacement.

Things like this happen no more than twice a year or less.  They have
never been abused so far and there is reason to assume they will be
abused in the future.

The CVS policy is most important for new developers as it puts our
traditions and rules into writing.  Telling them that feature removal is
strictly forbidden would IMNSHO just not reflect the way things are
handled.

> If you want you can write this down in the rules,
> After you reverse your commit!!!!!

You could try doing something *constructive* for a change and propose a
better wording instead of flaming.

Maybe you should reread the thread again.  There were 4 people
participating.  Dominik was in favor of the change, Reimar raised a few
points but said they were non-issues in the end.  The way it looks to me
you are the only one raising a fuss about this.  Feel free to prove me
wrong by getting other people to post on your behalf.

And don't simply revert a commit that is obviously under controversial
dispute without even waiting _a few hours_ for me to answer your last
email.  This is beyond rude.

Diego