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

[Adam Jackson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20041004/fb2c0a65/attachment.pgp>