How can I best help with glibc packaging?
Hi, gotom, and others.
For a while, I will be able to work full time on Debian things, and
would like to help with maintain glibc for Debian. I don't aim at
becoming a co-maintainer as such, but working on the bugs reported
against glibc and sending comments and patches is what I had in mind.
How can I do this in the most helpful manner?
One thing I've already started (though with little visible effect so
far) is going through the bug list and trying to see if bugs still exist
in the current version (sid or experimental). I can then tag, retitle,
or close bugs, if that is acceptable, or just add comments to the bugs.
The glibc bug list is many hundreds of bugs long, and shortening it a
lot would be good. Now that we're not in any kind of freeze and that
2.3.5 is going into sid in the near future, I hope it will be possible
to fix even bugs with low severities.
If I file patches, is it better to make them against the newest version
in the archive (experimental or sid), or agains the Subversion
repository? The former would probably be easier for me, but either is of
course doable. Things that need changes to upstream source will have to
go into a dpatch file, and other things need to be normal patches
against files in debian/*, right?
Also, a different question: is there a known best approach to hacking on
the glibc package to keep development cycles short? A full build of the
package takes up to two hours for me, and even the fastest build of the
Debian package (using ccache, and commenting out most of the binary
packages, such as -dbg) takes over half an hour. Is there any way of
making this faster without buying faster hardware?
Reply to: