Could it be the glibc maintainer went on a month's vacation to the Amazon, where he could get away from pestering patch authors? :-) Seriously though, it is likely your patch was lost in the maintainer's daily email shuffle. I am willing to bet the glibc mailing list is not a quiet one. And you're not the only one sending in patches or requests directly to the maintainer. And then there's spam ...
But sometimes patches get ignored, be it because the maintainer was too busy to look at it (see above), or it just didn't excite them enough to be worth the effort of merging it in.
So your patch didn't get accepted on your first try. Putting it up on some random webpage and then forgetting about it just shows the maintainer was right to ignore your patch! Your patch must have been just a quick hack, probably not a lot of effort, for you to just throw it away like that. Who wants that kind of coder as a contributor? I certainly do not!
So if at first you don't succeed ... keep trying. If you care about your patch, and if you believe it is important, keep up with the glibc codebase, and keep resending your patch. Sometimes patches get accepted because the author shows good skills and persistance. Most of the time they are accepted because the author shows good skills, persistance, and good grace.
If you believe you did good work, and that your patch is useful, here is what I recommend you do:
Maintain your patch in sync with the codebase, and kindly (and without a lot of fuss) resend your synced patch to the maintainer every week for four weeks. If after four tries you still do not get a response, post your patch on the development mailing list and ask (kindly) why your patch is being ignored.
Either you will be told flat out what is wrong with it, or it will get accepted. You will learn something either way...
Hacking Gates, Da Man
I suddenly decided some weekends ago that I needed a new file server, immediately. I didn't want to wait for another pay period to buy it, so it had to be really cheap. I would be the only one using it, so it didn't have to be blindingly fast or powerful. But it had to be adequate for NFS and SAMBA file sharing, and for learning Apache, MySQL, and PHP.
So I bought a used XBox, put in a solderless modchip, bought an 80 GB IDE hard disk, and installed Debian GNU/Linux 3.0 r0 with a modified 2.4.20 kernel on "Da Beast." I did not install X or sound drivers on it, and I've configured it to run headless; if / when I need to, I log in through SSH.
Cost of 733 MHz Pentium III, 64 MB RAM, 80 GB HD Linux file server? $308 US
Rise, Phoenix, from your ashes ...
Now that I have plenty of extra storage space on NFS, I can hack again on my old and long-neglected Sega Dreamcast and Broadband Adapter. :-)
I have a Sega Dreamcast with Broadband Adapter, which I bought in February 2001, to hack around with game programming on KOS. It was not getting a lot of play time lately, so I looked into other uses for it. Wonderfully, there are Dreamcast ports of eCos and RedBoot, Linux (here and here), and NetBSD. There are also two homebrew operating systems for Dreamcast: NewOS and KOS, which I already mentioned. NetBSD/Dreamcast and KOS are the most active at the moment.
I burned a CD-R with RedBoot, with which I interact through the Dreamcast's serial port. From RedBoot, I can load eCos, Linux, or NetBSD from NFS. I configured these to run without X and sound drivers. Once loaded, I interact with the OS through the serial port or through SSH.
Note: RedBoot, eCos, Linux, and NetBSD on Dreamcast can be configured to use the TV or VGA adapter output and a Dreamcast keyboard for the console, but I am not interested in that.
My Dreamcast is to be used in learning operating systems programming. Before, when I only had one computer available for hacking, I took things easy because I didn't want to cripple my one and only system. After all, I have other things I want to hack on besides operating systems.
With the Dreamcast, I can experiment and break things all over the place and not worry one bit. I am keeping two copies of each operating system's root filesystem on NFS (that's why the XBox NFS server has an 80 GB hard disk, although it is still overkill). If I break something, I can just reboot from the stable copy, figure out what I did wrong and fix it.
Mono Documentation
In order to continue to contribute to the Mono documentation effort, I am writing a few Gtk# mini-applications, and I am documenting the process through which I am constructing them. This documentation will appear as case studies in the GNOME.NET section of the Mono manual.
One of the mini-applications is, surprise, surprise, a Gtk# rewrite of GNOME Calculator. :-) The version of the code which will be used for Mono's documentation will not use GNOME Calculator's fixed precision math engine. But I will eventually break out GNOME Calculator's math engine into a shared library, and interface with it from the Gtk# GUI with P/Invoke.
Learning Apache, MySQL, and PHP
I bought two O'Reilly PHP books, Programming PHP and Web Database Applications with PHP and MySQL. I devoured these really fast and started to modify the code samples, scripting little test pages to my heart's content. PHP has been the easiest and most fun web server scripting language I've ever worked with. I can definitely see why there are so many PHP-based sites out there.
The purpose of this detour into PHP is two-fold: my free software projects are going to need a homepage of their own if they're going to contribute to free software world domination. I am learning PHP so I can maintain these homepages. The other purpose in learning PHP is that I am helping out a few free software organizations with the upkeep of their web sites, and some of them use PHP extensively.