On Mon, Jun 6, 2022 at 8:12 PM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > On Mon, Jun 06, 2022 at 10:22:03AM +0300, Amir Goldstein wrote: > > 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. > > Every one of these asks adds friction for patch authors. For code that > has already shipped in a Linus release it's a reasonable ask, but... > > > 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 - > > ...WHY? > > This is a fix for a new ondisk feature that landed in 5.19-rc1. The > feature is EXPERIMENTAL, which means that it **should not** be > backported to 5.18, 5.15, or any other LTS kernel. New features do NOT > fit the criteria for LTS backports. > > That's why I didn't bother attaching a fixes tag! > > > 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. > > This fix **WILL NOT APPLY** to 5.18! > I stand corrected. Sorry for the noise. Amir.
