On Mon, Jun 6, 2022 at 8:24 AM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > On Mon, Jun 06, 2022 at 08:29:40AM +1000, Dave Chinner wrote: > > On Sun, Jun 05, 2022 at 09:35:43AM -0700, Darrick J. Wong wrote: > > > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > > > It is vitally important that we preserve the state of the NREXT64 inode > > > flag when we're changing the other flags2 fields. > > > > > > Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx> > > > --- > > > fs/xfs/xfs_ioctl.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > Fixes tag? Thank you Dave! > > Does this really need one? I say why not. I am not looking for a fight. Really, it's up to xfs maintainers how to manage experimental features. That is completely outside of scope for LTS. I only want to explain my POV as a developer. You know my interest is in backporting fixes for LTS, so this one won't be relevant anyway, but if I were you, I would send this patch to stable 5.18.y to *reduce* burden on myself - The mental burden of having to carry the doubt of whether a certain reported bug could have been involved with user booting into 5.18.y and back. When you think about it, it kind of makes sense to have the latest .y in your grub menu when you are running upstream... Users do that - heck, user do anything you don't want them to do, even if eventually you can tell the users they did something that is not expected to work, you had already invested the time in triage. Sure, there is always the possibility that someone in the future of 5.19.y will boot into 5.18.0, but that is a far less likely possibility. For this reason, when I write new features I really try to treat the .y release as the true release cycle of that feature rather than the .0, regardless of LTS. If I were the developer of the feature, I would have wanted to see this fix applied to 5.18.y. Thanks, Amir.
