On Wed, Mar 14, 2018 at 05:45:40PM +0200, Amir Goldstein wrote: > 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. "..from [Christoph] to /dev/null..." would be more accurate. :( At this point I must give up the fiction that between prepping/reviewing patches for the next kernel and fixing problems in the current rc I have any time for stable kernel stuff at all. So, it's open season for anyone who /does/ have the time to pick out fixes and their dependencies, massage them into the appropriate stable kernels, and do at least the minimum xfstests QA (testing a v4, a v5 + everything, and a v5 + everything + 1k block size would be a good start). > 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. Aaaanyway, this i_rdev preservation fix is ok for 4.15, since (as Amir has pointed out) it originated in 4.15-rc1. --D > 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
