On 03.10.2018 00:24, Greg Kroah-Hartman wrote: > On Tue, Oct 02, 2018 at 11:46:11PM +0200, Helge Deller wrote: >> Hi Greg, >> >> On 02.10.2018 23:16, Greg Kroah-Hartman wrote: >>> On Tue, Oct 02, 2018 at 11:02:13PM +0200, Helge Deller wrote: >>>> please pull a last set of fixes for the parisc architecture for kernel 4.19 from: >>>> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.19-3 >>>> >>>> The major change is for parisc64 to use a 64-bit suseconds_t type to >>>> match what glibc expects for 64-bit userspace. It's an ABI change, but >>>> since we don't have a 64-bit userspace on parisc yet, it won't introduce >>>> a breakage. >>> >>> Isn't it a bit "late" in the release cycle for such a change? Why not >>> do this on the -rc1 release? >> >> I've tagged it for stable release. >> So, it can go in now, or just wait until -rc1 and go in later. > > Why is a major API change a viable stable change? Of course it's not. Esp. not if an API has been used already. IMHO, this case is really different though... > What bugfix does it provide? It fixes that code in stable kernels which would return wrong time values *if* someone would create a libc for 64-bit parisc and would run it with those "stable" kernels. Fixing it now has no side-effects, the change is a trivial 2-line-removal patch, would bring the code in sync with newer kernel source code, and it really fixes existing code. I still believe that this justifies for a backport. Nevertheless, if you really disagree, I'm fine dropping the backport to stable and will only push it in the next merge window for v4.20. >>>> Other than that we simply drop unused code and outdated gcc version >>>> checks. >>> >>> Why are those needed now? >> >> The patch in there which is by me changes one line simply cleans up a patch which >> went in during the 4.19 merge cycle. So it would be nice to have it >> added now before v4.19 gets released. >> The other two patches are trivial and just remove dead code. >> I rate them all as non-critical, but nice-to-have-in-v4.19. >> >> If you disagree I'm absolutely fine to wait with all of them >> for the next merge window. > > Normally I only let "bugfixes" into my trees at this point in time. > cleanups always wait for the next -rc1 merge window as that's what it is > there for. So I'd recommend waiting as well. Ok. Helge
