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

[Ivan Kalvachev]

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?

> > > It's just plain common sense.  If X starts a discussion about something
> > > on dev-eng and no consensus is reached and X proceeds with his plans
> > > nonetheless people will complain.  It's as easy as that.
> >
> > (You mean they will flame and we will ignore them.)
> > I complain against removing of this. Let see will you bring it back.
>
> I don't understand your last sentence.
>
> > > > 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?
Options are changed on regular basis, when needed. E.g. I'm sure you
know that "dfbopts" was removed as it is now suboption. This changes
program behaviour without removing any functionality. Other examples
are changing priority of audio/video drivers/codecs etc...
This is not big issue because the functionality is still present. Only
documentation must be updated.

On the other side removing functionality means removing code that does
something useful in a way that it is no longer possible to perform it
using mplayer. E.g. removing  dump support from mplayer (without
moving it to mencoder).


> 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.

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).

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