From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15714 invoked by alias); 25 Sep 2019 00:47:28 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 15705 invoked by uid 89); 25 Sep 2019 00:47:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=judge, yourself X-HELO: esa1.mentor.iphmx.com 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= Date: Wed, 25 Sep 2019 00:47:00 -0000 From: Joseph Myers To: Lukasz Majewski CC: Alistair Francis , Alistair Francis , Zack Weinberg , Arnd Bergmann , GNU C Library , Adhemerval Zanella , Florian Weimer , Carlos O'Donell , Stepan Golosunov Subject: Re: [PATCH v8 1/3] y2038: Introduce internal for glibc struct __timespec64 In-Reply-To: <20190923232109.735f898b@jawa> Message-ID: References: <20190918211603.8444-1-lukma@denx.de> <20190918211603.8444-2-lukma@denx.de> <20190923232109.735f898b@jawa> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-Path: joseph@codesourcery.com X-SW-Source: 2019-09/txt/msg00393.txt.bz2 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