This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v8 1/3] y2038: Introduce internal for glibc struct __timespec64
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Lukasz Majewski <lukma at denx dot de>
- Cc: Alistair Francis <alistair23 at gmail dot com>, Alistair Francis <alistair dot francis at wdc dot com>, Zack Weinberg <zackw at panix dot com>, Arnd Bergmann <arnd at arndb dot de>, GNU C Library <libc-alpha at sourceware dot org>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Florian Weimer <fweimer at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, Stepan Golosunov <stepan at golosunov dot pp dot ru>
- Date: Wed, 25 Sep 2019 00:47:19 +0000
- Subject: Re: [PATCH v8 1/3] y2038: Introduce internal for glibc struct __timespec64
- Ironport-sdr: ZHEnG/cH6wx0T/FPwXvEreIYr7M9v4bW5ESdtivnE6mCoCrnR5bDwui3aEY/cFQhj260u3zwEt 4V6DYkIuxhbLMUL/oA8jtlV1OtTYx6jH1poIMIcB3632Z82Gq+STQhu1U41ZDVq9jCR0z/Ua4o H5OZ8HpEbBRTZAZ/QcO2MX6cin1lTSx74gAVhWdYxC867aZOTAFIs1YiEi5+goCkXzGVba5xp5 qrIsMAMmmFXA0+M8K8Y+EICpGTZbyeGtXGk+okjKgf++OgjcaHaXaVZpgdX2D+MDZoEv8nYHay Cpc=
- Ironport-sdr: jdfs7ukz7tc2py9ZJ47uQ+sLm/xIpMxi0kXgr8JCSgdfPKr52LYlhqSRJblSWSAzTGOB/qPtxY tF8ZPa68ybxSMkDMFDN5wCQeOUKTgSI/Zz7CpY55rrBjfUy8LGpPojjEoNKBdkWvVvg4TiL4+l 12bwMtW25OSv0KUjPILv/oJ4zA9bsAgmW+mQ4d0CFXLqqY++a9/QGFde/oStXDqYbA0nXMsMvd GHPngtu1ff4ml2oOygTFBXxYoCnMNKtVEFuxr5IsMXb7RLaWZfZstWgBfbElHGb9ch/U+1wSQg W/I=
- References: <20190918211603.8444-1-lukma@denx.de> <20190918211603.8444-2-lukma@denx.de> <alpine.DEB.2.21.1909192014250.11875@digraph.polyomino.org.uk> <20190923232109.735f898b@jawa>
On Mon, 23 Sep 2019, Lukasz Majewski wrote:
> > > * include/time.h: Add struct __timespec64 definition
> >
> > This patch is OK.
> >
>
> If I may ask - are there any issues with pulling this patch to glibc
> -master branch?
Unless there have been other concerns expressed about this patch in
previous discussions, and unless you've discovered any problems with it
yourself, I'm expecting you to commit it to master. And that's generally
the case for most patches - if someone has explicitly judged it OK for
inclusion and there have been no other concerns expressed about it, it
should be committed (unless in a release freeze period or it depends on
some uncommitted patch, in which case the commit needs to be delayed).
I think it's generally for reviewers to say if their view is "I think this
patch is OK but we should allow more time for other people to comment",
rather than expecting patch contributors to judge when they need to wait
further after a patch approval.
--
Joseph S. Myers
joseph@codesourcery.com