This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc 2.27: two weeks left of active development

On Mon, 18 Dec 2017, Carlos O'Donell wrote:

> By submitting it for 2.27 you have the following consequences:
> * You need to convince maintainers for review during a precious period
>   of time when we're preparing the release and handling bugs.

That's basically why postponing submission until the actual freeze period 
would be a bad idea.  If you think a port is ready for 2.27 and want it in 
2.27, you should really be submitting it in the next few days so review 
can start before the freeze.  And the submission should have all the 
information needed, such as results from full glibc test runs for each 
supported ABI or other relevant configuration (using upstream GCC and 
binutils, with versions used specified) and confirmation that compilation 
test results for all the configurations added are 
clean (given use of suitable upstream versions of GCC / binutils / Linux 
kernel).  And now details of the state of static PIE support should be 
provided as well (may be absent or untested, but say so explicitly if so 
as that implies it needs listing on the PortStatus page as such).

> * You need to have confidence your port is ready and you haven't made
>   any real ABI mistakes. Any last minute mistakes that slip through
>   will become permanent ABI artifacts for the port.

There are always infelicities in the ABI that mean future changes need 
compat symbols for existing ports.  Provided the kernel port is upstream 
(and thus the kernel/userspace ABI is known and stable), which I think we 
agreed is a basic requirement for getting a glibc port upstream (the 
kernel port should at a minimum be in linux-next and expected to be in 
Linus's tree for the next release), and provided the glibc test results 
are reasonable (I've suggested < 20 architecture-specific failures, using 
upstream GCC and binutils, with no failures in the compilation tests), I 
don't think the ABI provides a particular reason to aim for a given 
release cycle or not.  Of course ABI issues need to be considered in the 
review, and the port submission should explain what ABIs are supported by 
the port (including details of e.g. whether hard-float and soft-float are 
different ABIs, if applicable).

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]