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@lst.de 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.