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

Diego Biurrun diego at biurrun.de
Wed Feb 8 12:05:04 CET 2006


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.

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

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'm sure most of people don't care about wording, as these are not
> laws and nobody goes to jail for braking them. But this text is mostly
> for new developers that may decide that 3dfx and tdfx, mga_vid are
> really obsolete...

New developers are told just to commit in their area at first.  New
developers stepping outside their areas has never really been a problem.
Sometimes a new dev is a bit eager, he gets told to be more wary,
problem solved.

Diego




More information about the MPlayer-dev-eng mailing list