On Wed, Mar 14, 2018 at 2:49 PM, Christoph Hellwig <hch@xxxxxx> wrote: > On Wed, Mar 14, 2018 at 11:33:14PM +1100, Dave Chinner wrote: >> IOWs, if all you're doing is relying on "fixes" tags to determine >> what /might/ be needed in a stable kernel.org update, then your >> stable backport process is fundamentally broken. You're going to >> break things and make stable kernels worse for your users, not >> better. > > Agreed. As someone who has done a fair share of -stable backports > for a customer: The backport to the last stable release is fairly > easy, as it means picking everything that is not clearly a feature > or cleanup, and you're generally still familiar with the code. It > still needs quite a lot of QA time. Backports to older long-term > stable bases can become much more hairy very quickly. > > In either case Fixes: tags don't help at all. What helps is having > one person doing the backports continiously so that they are in the > loop. So when I had a paying customer for the backports it was > fairly easy for me as I knew where I left off, need to pick up again > and remember the pitfalls of the old stable code. Randomly Ccing > stable or someone working from Fixes tags has none of those benefits. > And espesically the CC stable is dangerous as there is no QA or > detailed review performed. Got it. I also read between the lines that the responsibility of herding the stable patches has shifted from you to Darrick in the last development cycle. Eventually, I got my answer to how I should make sure my patch finds its way to stable, so I'm good with that. Only wondering out loud if there should not be a process to expedite last cycle regression fixes, such as my patch, to the stable tree. After all, we are at 4.15.9 and I reported the regression even before v4.15 was released. Thanks, Amir. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
