[lkml]   [2018]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT PULL] parisc fixes for kernel v4.19
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:// 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? What bugfix does it

> >> 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.

I'm more "worried" about the api change listed above.


greg k-h

 \ /
  Last update: 2018-10-03 00:25    [W:0.051 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site