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? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
