John Anthony Kazos Jr. wrote: [I wrote] >> BTW, of course it doesn't suffice to say "we can't remove it yet" after >> the due day. There need to be well-founded reasons for another >> deferral. [...] > So when this sort of thing comes up, why can't somebody put together a > trivial patch to update feature-removal-schedule.txt? If a deadline is > reached, and a removal is attempted and aborted, the deadline should be > extended, obviously. So then the patches can be resubmitted (or recreated, > even) when the new deadline is reached, da capo.
<stating_the_obvious> Yes, of course. When a decision is reached to defer or even abort a feature removal process, the maintainer in charge should take care that such an updating patch goes to feature-removal-schedule.txt. So if there are outdated entries in feature-removal-schedule.txt, then it's because someone forgot something, and it won't hurt to ask the responsible person if he knows of a change in the removal plan. </stating_the_obvious> -- Stefan Richter -=====-=-=== -=-= ---=- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
