On Wed, Nov 06, 2024 at 08:06:40AM +1100, NeilBrown wrote: > On Wed, 06 Nov 2024, Chuck Lever wrote: > > But more importantly, the problem with the automatic backport > > mechanism is that marked patches are taken /immediately/ into > > stable. They don't get the kind of soak time that a normally-merged > > unmarked patch gets. The only way to ensure they get any real-world > > test experience at all is to not mark them, and then come back to > > them later and explicitly request a backport. > > > > And, generally, we want to know that a patch destined for LTS > > kernels has actually been applied to and tested on LTS first. > > Automatically backported patches don't get that verification at all. > > I thought it was possible to mark patches to tell the stable team > exactly what you want. Greg certainly seems eager to give maintainers as > much control as they ask for - without requiring them to do anything > they don't want to do. Yes, Greg and Sasha want to do something constructive. I see suggestions flying by from time to time. The last specific one I think was rejected by Linus. It appears to be an ongoing conversation. > If you have a clear idea of what you want, it > might be good to spell that out and ask how to achieve it. Perhaps having a separate review process, where each patch in nfsd-next is audited just before the merge window to see whether it should be marked for stable, would help. Keeping written notes on these decisions would also be helpful; Greg asks when an explicit backport request comes by why it wasn't marked when it went into Linus' branch. Making it easier / more automated to test-apply such patches to LTS kernels is also something to think about. I have nightly CI for those branches, but it tests what is already in the LTS queue rather than testing NFSD-specific patches. -- Chuck Lever
