On Mon, Nov 30, 2020 at 02:52:11PM +0100, Paolo Bonzini wrote: > On 30/11/20 14:28, Greg KH wrote: > > > > Lines of code is not everything. If you think that this needs additional > > > > testing then that's fine and we can drop it, but not picking up a fix > > > > just because it's 120 lines is not something we'd do. > > > Starting with the first two steps in stable-kernel-rules.rst: > > > > > > Rules on what kind of patches are accepted, and which ones are not, into the > > > "-stable" tree: > > > > > > - It must be obviously correct and tested. > > > - It cannot be bigger than 100 lines, with context. > > We do obviously take patches that are bigger than 100 lines, as there > > are always exceptions to the rules here. Look at all of the > > spectre/meltdown patches as one such example. Should we refuse a patch > > just because it fixes a real issue yet is 101 lines long? > > Every patch should be "fixing a real issue"---even a new feature. But the > larger the patch, the more the submitters and maintainers should be trusted > rather than a bot. The line between feature and bugfix _sometimes_ is > blurry, I would say that in this case it's not, and it makes me question how > the bot decided that this patch would be acceptable for stable (which AFAIK > is not something that can be answered). I thought that earlier Sasha said that this patch was needed as a prerequisite patch for a later fix, right? If not, sorry, I've lost the train of thought in this thread... thanks, greg k-h _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
