LPC2020NotesGlibc

Notes taken at the GLibC BoF

Attendees: 95

Pre-meeting: changelog transition similar to GCC model worked well for glibc. Or rather vice versa, glibc came first, w/ gnulib's purely automated generation, plus quirks file. ChangeLogs are autogenerated on release branches. RMS okayed no manual changelog entries at all. Instead, detailed git commit messages.

Release plans: two releases in 2021. Key enabler: patch review.

Florian convinced Carlos patch review is even more important than bz.
Patch review challenge from last year: 100 reviews/day .... actual range 10ish/day
554 community reviews in last year
patchwork running on new sourceware.org, makes it easier to find unreviewed patches
Maybe organize regular meetings/schedules for intensive review sessions?
Online, conversational chat driven coordination a possibility?
Preferential focus / feedback on new contributors is important to welcoming atmosphere.
Automated CI builds from patchwork would be useful to verify non-regression.
Distros should ship git-pw clients.

Sourceware mailman complications:

mail header munging is made necessary by internet anti-spam processing, it is a trade-off
patchwork submissions bypass some of this, since they bypass mailman reflector processing

Other experiences with patchwork-CI integration

Laura Abbott on kernel experiences: CKI project, see also testing/fuzzing microconference
The very volume of patches for the kernel started hitting performance limits of patchwork/CI
Ordering / dependencies between patches has been a problem
glibc volume is smaller
Florian: volume is smaller, but conflicts in Makefiles, symbol lists occur, ergo git merge conflicts; could be automated, not inherently difficult, just a build system change (not fun)
What kind of CI cycle time is good enough? glibc: 70 targets => 3 hours
Obscure architecture failures happen
Some machines take much much longer to run through tests (scarcity / speed), a few hours latency mostly ok, esp. if the load is borne by other machines.