[lkml]   [2001]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Date said:
> Therefore it's the maintainer's job to submit coherent patches and
> accept to see inconsistent CONFIG_* references be removed from the
> official tree until further patch submission is due.

Maybe. But you tend to include the latest MTD code in your tree, for
example, and hence the defconfigs have the new options in. Is it really
worth your time to produce separate defconfigs without it before feeding
your changes upstream?

> Otherwise how can you distinguish between dead wood which must be
> removed and potentially valid symbols referring to code existing only
> in a remote tree?

By periodically publishing a list of the potentially-obsolete symbols as ESR
has done, and _not_ removing the ones which people speak up about. It's not
as if this is something which needs to be done more than about once a year.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:27    [W:0.129 / U:1.328 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site