> >> +2.0.2: RC-SERIES RULES > >> + > >> +Rules on what kind of patches are accepted after the merge window closes. > >> +These are patches targeted for the kernel rc-series of a kernel prior > >> +to its release. > >> + > >> + - it must fix a reported regression > >> + - it must fix a reported security hole > >> + - it must fix a reported oops/kernel hang > > > > - it must fix a bug. > > Well that's for certain, but there is a difference between a general > notion of a bug and the type of bug fixes that should go in during the > rc-series. This documentation patch highlights the difference. Yes, and I'm trying to tell you that this documentation patch is wrong. Non-intrusive bugfixes _are_ welcome after -rc1. > > I do not think the 'reported' requirement is there in -rc, > > Well if its not reported how else would you find out about it during > the rc-series? And if its something easily triggerable that should > have been fixed earlier, not late in the rc-series. 'reported' means 'someone is hitting that bug' in that context. If you do code inspection on drivers/foo/bar.c and find that it will hang on may 13, 2017; then that's a bug but not "reported" one -- users are not hitting it. Such bug may be uninteresting for -stable, but would probably be ok for -rc. > > and yes, > > compile-fixes etc are welcome. > > Sure, but what are these doing so late in the rc-series? Bugs happen :-). > > Non-intrusive bugfixes too, afaict. > > It really depends on what you mean but generally no, and this is why I > think this clarification is important. I believe you are wrong. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
