Yeah, well my blog posts have dropped off drastically lately. It’s probably mostly due to my recently having taken on maintainership of GNU Wget. I’ll give an update on what I’ve been doing with that.
Bug tracking
One of the first things I did was to go through the TODO list on the Wget repository, and issue reports on the mailing lists, and transfer it all to a bug tracker, so we can actually see what needs fixing, and what we’ve fixed, and keep it all semi-organized somehow. In spite of reservations, I decided to move them all into GNU Savannah’s bug tracker, because Wget already has a presence on Savannah, so it would require a minimum of setup. On the other hand, as I was already well, Savannah’s interface positively sucked. It’s cumbersome to set up bug submission form fields, it’s cumbersome to arrange their order, it’s cumbersome to search for specific kinds of bugs, …but at the end of the day, it does the minimum that I decided I needed, and required relatively little setup. Maybe someday we’ll move to Bugzilla… *shrug*
Moving the repository
Another thing I did pretty soon after taking ownership of Wget, was to move hosting of the Wget source code repository from dotsrc.org (formerly known as sunsite.dk; they still host our primary mailing list) to my own VPS (the one this blog runs on), under the domain addictivecode.org. I didn’t do this just because I’m a control-freak and want absolute power over everything (though this may be the case 😉 ), but after several weeks of trying to get the attention of the dotsrc staff so I could get commit access to the repository (and actually freakin’ write code for the project I was supposedly maintaining), I decided enough was enough, and used svnsync to create an identical copy of the Subversion source code repository, so I can give myself access. 🙂
New mailing lists
Another motivation for moving the repository was that I desired to have a mailing list for receiving commit notification, so everyone who’s interested can see what development is going on. Mauro Tortonesi, the previous Wget maintainer, related that he’d tried to get the dotsrc staff to put such a thing in place, but to no avail. So, I created a list for this purpose, which also receives bug report change notifications from Savannah; and another very low traffic one for communication between just the developers who have commit access.
The Wget Wgiki
Next was to complete the migration from a web presence at dotsrc.org to gnu.org. The original plan was to have the entire web presence hosted at the gnu.org site; however, at the same time, I was scheming about putting a wiki in place for collobarative definitions of specifications for future major improvements to Wget. When I finally got around to slapping MoinMoin onto my server (which I chose primarily because of familiarity due to my involvement with Ubuntu), I began to realize just how much better it would be to host as much of our main informational content on the wiki. So, the end result is that the dotsrc site no longer exists (or, more accurately, redirects to the GNU site); and the GNU site is a basic informational stub, that points to the new wiki site (dubbed The Wget Wgiki), which holds all the real information.
Development schedule planning
Another thing I started doing early on was to draw up a project plan (Gantt chart) to try and target when we would release the next version of GNU Wget, 1.11. Since it was pretty much just me and Mauro doing active development—who both have day jobs—I tried to be extremely generous with the amount of time it would take us to get things done. Wound up with a target of September 15. I’m confident we would’ve made it, too: we were on-target in terms of development, but there ended up being some legal issues with the new version 3 of the GNU GPL, and the exemption Wget needs to make to allow linking with OpenSSL, an incompatibly-licensed library that handles encryption for things like HTTPS. We’re still waiting for the final concensus from the FSF legal time.
At the moment, we’re not code-ready anyway; but we would’ve been if we hadn’t been somewhat demotivated by the fact that our code-readiness or lack thereof isn’t going to impact when we can release. I chose to work more on the wiki instead of code at that point, and on evaluating decentralized SCMs as potential replacements for Subversion. Now that I’m doing most work on a laptop, a DSCM is convenient. So far, Mercurial seems like a good bet, but we’re still discussing it on the list. Several folks prefer Git, but Git seems to be heavily Unix-centric, with limited support for other platforms; given that Wget is also used on other platforms, there seems to be some merit in preferring a more multiplatform solution; but we’ll see.