[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