On Wed, 2 May 2007, John Anthony Kazos Jr. wrote: > stefan richter wrote:
> > We have to try to avoid this waste of resources when we put > > features into feature-removal-schedule.txt. That's what I meant > > with "the hard part" in the other post. > > > > 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. Of course if there are such reasons, it means > > something went wrong when the feature was put into removal > > schedule. (Some facts weren't known.) > > 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. argh. the whole point of this discussion is to come to a *consensus* on what should be in that feature removal file. there is no point in creating and submitting patches, either to update that file or remove kernel features, until enough people *agree*. at the risk of being head-bangingly repetitive, that's what the wiki page is for: http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed go. read. comment. update. add. remove. it's a wiki. don't make me pull this car over and explain it. :-) rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page ======================================================================== - 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/
