Planning for glibc releases --- What should go into glibc 2.40?

Planning for glibc releases --- What should go into glibc 2.40?

[Carlos O'Donell]

Community,

In a recent Monday Patch Queue review meeting a suggestion was raised
by Adhemerval to try doing more detailed plans for the glibc releases.

The benefits of a detailed plan for a 6-month development cycle
would be that it allows reviewers to support patch review for the
committed plan.

We do something similar as we approach the end of the development
cycle by recording blockers in the release wiki and then reviewing
and making progress on the blockers.

The goal would be to do something similar but on a monthly cadence.

For example:

Month 1 - Feature 1
Month 2 - Fix 2
Month 3 - Enhancement 3
Month 4 - Hardware Enablement 4
Month 5 - Feature 5
Month 6 - Blockers

We already had a "Planning" section in the release template page
so I'm suggesting we reuse that section and plan against the months:

https://sourceware.org/glibc/wiki/Release/2.40#Planning

I have added 2 things I'd like to see this release and put them against
February and April. My goal is to commit to these two items and support
getting them completed in that month. If they aren't complete then we
can re-evaluate. Development should proceed as normal but during patch
queue review I will give priority to the items in the plan and seek
reviewers for those items to attempt to complete the review (similar to
how we handle blockers in Month 6).

I don't want to define a complex process here. If there is something that
you would like to see happen then add it to the plan and if a given month
gets too busy then we'll discuss it as a community.

Please add items to the plan :-)

Thoughts?

I'm particularly keen to hear if the distributions have any features,
fixes, or enhancements they want to see completed.

-- 
Cheers,
Carlos.

Re: Planning for glibc releases --- What should go into glibc 2.40?

[Paul Zimmermann]

       Hi Carlos,

> https://sourceware.org/glibc/wiki/Release/2.40#Planning
>
> Please add items to the plan :-)

I don't think I have write access to the wiki, but I'd like to see the new C23 math
functions (acospi, asinpi, atanpi, atan2pi, cospi, sinpi, tanpi, exp10m1, exp2m1,
log10p1, log2p1, rsqrt) available in GNU libc.

Some are already available in the Intel Math library, in the FreeBSD library, in
CUDA or in RoCM.

Best regards,
Paul

Re: Planning for glibc releases --- What should go into glibc 2.40?

[Joseph Myers]

On Wed, 14 Feb 2024, Paul Zimmermann wrote:

>        Hi Carlos,
> 
> > https://sourceware.org/glibc/wiki/Release/2.40#Planning
> >
> > Please add items to the plan :-)
> 
> I don't think I have write access to the wiki, but I'd like to see the 
> new C23 math functions (acospi, asinpi, atanpi, atan2pi, cospi, sinpi, 
> tanpi, exp10m1, exp2m1, log10p1, log2p1, rsqrt) available in GNU libc.

I think this wiki list is for things that already have patches - not for 
aspirations that some feature would be nice to have.

I hope to work on these functions at some point, but it depends on time 
available between other projects (and my time available will be very 
limited from April through July in general).  As previously discussed, the 
functions would start with type-generic templates where possible (thereby 
making the functionality available for all formats, including legacy ones 
such as IBM long double, without needing individual implementations for 
each format - we don't want functions for only a subset of formats - and 
dealing with all the documentation, test inputs, ABI baseline etc. updates 
at that point), and then faster and more accurate implementations can be 
incrementally added for particular (function, format) pairs later (with 
benchmarks added for any function being replaced to show that the new 
implementation is indeed faster).

Note that your list omits the logp1 alias, and the compoundn rootn pown 
powr functions.  Also, there are functions we have from TS 18661-1 whose 
prototypes changed in C23: we need to change the prototypes of fromfp 
functions (see bug 28327), with backwards ABI compatibility similar to 
that for totalorder.

On the C23 front, there is at least one feature where a patch has already 
been posted but needs review and updating (to put things in the latest 
NEWS section, at least): the new optional time bases (posted by Yonggang 
Luo last June).  There are also several C23 features where we don't yet 
have patches, but that would be simpler to add than the new libm 
functions.

-- 
Joseph S. Myers
josmyers@redhat.com

Re: Planning for glibc releases --- What should go into glibc 2.40?

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

> In a recent Monday Patch Queue review meeting a suggestion was raised
> by Adhemerval to try doing more detailed plans for the glibc releases.
[...]
> We do something similar as we approach the end of the development
> cycle by recording blockers in the release wiki and then reviewing
> and making progress on the blockers.
> 
> The goal would be to do something similar but on a monthly cadence.
> 
> For example:
> 
> Month 1 - Feature 1
> Month 2 - Fix 2
> Month 3 - Enhancement 3
> Month 4 - Hardware Enablement 4
> Month 5 - Feature 5
> Month 6 - Blockers
> 

It's worth trying. 

I mean, the effect of the freeze is usually that there's a bunch of
features going in at the last moment, leading to testing and fixing...
If we can distribute that better over the development period that
would be great.

How about a "halfway tag" on master after ~3 months, maybe 
accompanied by tarballs, as reference if anyone wants to do machine
testing?
(The mips-o32 clone3 patch was in very early...)
Not as "release" in any way, none of the "release guarantees", but 
we could at least try to have patchsets / groups of features complete
before.

> I'm particularly keen to hear if the distributions have any features,
> fixes, or enhancements they want to see completed.

BZ #23960 (yes I know I'm nagging :o), and sorry I dont remember
offhand what the latest state was), BZ #24050

Cheers,
Andreas

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]