Recently, I found it hard to contribute to open source in general and Debian in particular. There are several reasons for that: beginning with less free time to contribute and continuing with feeling my contribution becomes more and more routine and thus less interesting / challenging.
Yesterday I found the time and motivation to upload fixes to 6 of my packages. I thought it might be interesting to share the reasons for this motivation burst, as it can demonstrate how each of us can affect others.
The final trigger was seeing (= getting svn diffs) Baruch Even working on the libhdate package (which is co-maintained as part of debian-hebrew). Prior to that I had people showing interest in my packages, helping with solving bugs, sending patches and even one guy becoming a co-maintainer of a package of mine. Oddly, most of them are ubuntu users.
I’m not looking for others to do my work or do it for me, but getting help is always fun and motivating. Also, working with other people creates commitment as they wait for something you should do, or waiting for you to use what they’ve done. For me this starts a positive snow ball which ends with better packages for me and happier people after receiving credit for their work (usually a changelog entry and a thank you mail).
So go on, and inspire people (:
Earlier this month Kumar Appaiah opened a bug against the culmus package as part of the stable -> unstable piuparts upgrade tests.
First, I’m proud in Debian to have these tests. Thanks for the people involved with running them, parsing the log files and reporting the bugs. I really feel the lake of such checks in commercial distributions I work with.
After finding the time to get to the bottom of the bug, and talking with Kumar, it seems most of the bugs found in the test are similar. I think this might indicate something wrong in a more basic level of the package handling.
The source of these bugs is how to handle files which were conffile in version x, but aren’t included in version x+1 (as a regular file). In the common situation, the conffiles are removed only during the purge process and not during upgrade or removal. But if a conffile doesn’t exist in the x+1 package, no one will “own” it after the upgrade, and no will purge it in due time.
This is why changing conffiles can result in extra files on our system, which is the problem discovered by the recent piuparts test.
One solution will be that each package maintainer will add the necessary code to the maintainer scripts to remove the file on upgrade. A second solution is to decide the wanted behavior in such a case and to have dpkg handle it for all packages.
The behavior can be to remove the old conffile during the upgrade (postinst script) or to dynamically add it to the list of files owned by the package. Although technically possible, I’m not sure if the second method is “legal” with the debian policy.
I thought it would be better to hear others’ opinions before submitting a wishlist bug about this.
With the release of version 2.3.1 and upload to unstable, I started to wonder if it’s time for another bug triage for openoffice.org package.
The last triage targeted bugs older than version 2.0.0, but now I’d like to target versions 2.0.0 to 2.2.1 (which is in testing right now). Preferably getting answers for 2.3.1 in unstable.
Another goal for the triage is to add up-to-date version info to the bug reports, as I think it makes the maintainers’ life a bit easier.
The actual question is whether to start now or to wait for version 2.3.1 to enter testing. The problem is that I don’t know when would this happen. It took a “while” for 2.2.1 to do so.
MovableType, the blog infrastructure, is announcing today the availability of an open source version.
While this is a good step in the right direction, it seems that it will take a while for this project to stand on his feet. The status page shows that the required infrastructure for an open source project isn’t available yet. The nightly build link at the getting-the-source page leads to an 404 message which contains info about how to purchase a license.
The download links use the word free (as in gratis) , and show a non-free (as in libre) license. Quite shameful after reading the “we’re going open source” announcement.
On the other hand, the source code is already available on the SVN, including the appropriate GPL headers.
To conclude, it seems that the release announcement was a bit too early, and it might have been better to build some more infrastructures for the project first. But it will be very interesting to see the blogoshphere hitting up while MovableType and WordPress compete, and hopefully also cooperate.
Apache’s mod_jk has nice load balancing features. They work quite well for me with Jboss. The basic configuration is to install Jboss on several machines and have an Apache to load balance them.
But while the load balancing is good, the Apache machine becomes a single point of failure. I was asked how to overcome that. The main principle I want keep is the “keep it simple, stupid” principle.
Doing a round robin DNS between two machines is nice, but doesn’t really provides real the load balancing (as it always does 50/50). It also doesn’t check for the the load before it does the balancing.
Other options like using mod_backhand and mod_proxy_balancer all leave me with the same single point of failure problem. That’s why I prefer to use an active/passive cluster to make sure Apache can move to another server in case of a failure. The IP address the users get is a virtual (or floating) IP, which can “jump” between the cluster nodes.
There are several ways to create that cluster, but that’s probably for another more general post.
I’ll be happy to hear other opinions…