On Fri, Feb 23, 2018 at 10:33:24AM -0800, Darrick J. Wong wrote: > On Fri, Feb 23, 2018 at 10:44:46AM +1100, Dave Chinner wrote: > > On Thu, Feb 22, 2018 at 02:49:27PM -0600, Eric Sandeen wrote: > > > > > > > > > On 2/20/18 3:02 PM, Dave Chinner wrote: > > > > On Tue, Feb 20, 2018 at 08:33:47AM -0800, Darrick J. Wong wrote: > > > >> On Tue, Feb 20, 2018 at 09:09:22AM -0600, Eric Sandeen wrote: > > > >>> (resend, somehow I keep missing reply-all) > > > >>> > > > >>> That would be much faster than at least our historical progression > > > >>> for new features: > > > >>> > > > >>> * Experimental for $LONG_TIME > > > >>> * Drop experimental for $SIGNIFICANT_TIME > > > >>> * Make default after that > > > >> > > > >> ISTR Dave once telling me that he usually waited ~4 kernel releases to > > > >> drop the experimental tag and then another year to turn it on by > > > >> default in mkfs. I'll grant you that seven kernels went by before > > > >> EXPERIMENTAL went away, so I don't think we need to wait a whole other > > > >> year. How about turning it on by default in July or so? > > > > > > > > The wait time for "supported -> default" is so that distro's have > > > > time to move to a feature supported kernel before they pick up a new > > > > xfsprogs release that turns on that feature by default. this mostly > > > > avoids the problem of distros accidentally turning on a feature that > > > > is still experimental in their kernel.... > > > > > > Speaking for Fedora, it brings userspace & kernelspace into a distro > > > together, so that's not a problem. Speaking for RHEL, it's a long term > > > distro that knows darned well that mixing and matching new & old requires > > > care, if it's done at all. > > > > Right, but other distros like debian have async kernel and userspace > > package update schedules. It's not until they "freeze" for a release > > that things like userspace and kernel versions are expected to have > > feature matches. e.g. we could upload xfsprogs 4.16 with reflink > > enabled by default to unstable the moment it is released. At that > > point in time, the default unstable kernel might be a 4.15 kernel > > (or older). Worse, the current installer kernel might be be even > > older, even though the nightly build picks up the new installer > > package we uploaded. > > > > It's unecessary angst and pain that is easily avoided by having some > > delay between saying "this is suported now" and "every new > > filesystem will use it by default".... > > Right, and I was suggesting 4.18 or so, which gives distros 4 months to > update their kernels... but now I looked at my notes from 2015 which > said "reflink on by default in 420??", snickered at my own juvenile > humor, and reflected on how that wasn't such an inaccurate forecast > after all. :P > > So, uh, how about 4.20? That'll give everyone a good 9 months to pick > up a new kernel. Fine by me. > (As for debian, I thought they /were/ doing the "update kernel and then > matching xfsprogs" dance, at least for stretch and beyond.) It's the rolling unstable branch that is the problem here. Things tend to move back to the testing branch relatively sanely, but even then you can have much bigger gaps between the default kernel version and userspace if a userspace package migrates before the kernel update occurs. And when you factor in things like non-maintiner uploads, things can get out of step very easily.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
