nico@cam.org 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.
-- dwmw2- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 23 2001 - 21:00:38 EST