Official procedure for feature removal ? / was: Re: Dead code: programs/Xserver/iplan2p[248]

[Ely Levy]

On Mon, 4 Oct 2004, Adam Jackson wrote:

> On Monday 04 October 2004 21:31, Roland Mainz wrote:
> > Adam Jackson wrote:
> > > These three directories appear to be completely abandoned.  I can't find
> > > any reference to them in any of the live configs or Imakefiles.
> > > According to xf86's CVS history they haven't been substantially modified
> > > in eight years. Unless someone speaks on their behalf within, say, two
> > > weeks, these three are getting deleted.
> >
> > It would be nice if you could file a bug into bugzilla to track that
> > issue (and for the .../Xserver/ilbm/ code, too) that there is an
> > official record of the removal.
>
> But of course, #1534 and #1535.  Hopefully it's obvious that "RFD" stands for
> "Request for Deprecation".
>
> > BTW: What about setting up an official procedure for such a feature
> > removal similar to what Sun does in Solaris: First they annouce the
> > removal of a feature ("EOL notice", "EOS notice"(=end-of-support)) in
> > their release notes and then one of the _following_ releases then
> > removes it (e.g. there is always one release cycle time for customers to
> > scream&rant)).
>
> Definitely.  gcc uses the same process to deprecate outdated or unmaintained
> targets, and it seems to work pretty well there.  My only complaint would be
> that it would have been really nice to have some deprecation warnings in the
> 6.8 release notes.  Oh well.
>
> If we did decide on such a policy, would I have to restore xf24_32bpp to the
> build?  I cut it since no in-tree driver uses it anymore, and the only one
> that did use it required a non-default configuration to use it.
>
> - ajax

Gcc uses that to remove dead targets not dead code, if there is a code
that nothing uses why wait a whole 2 release cycles before removing it?
things change and get rewritten and code gets removed.
The only thing I guess is to ask netbsd people what they use that code
for.

Ely