Blog by Sumana Harihareswara, Changeset founder
Hacking on Mailman using Launchpad and Bazaar
Hi, reader. I wrote this in 2015 and it's now more than five years old. So it may be very out of date; the world, and I, have changed a lot since I wrote it! I'm keeping this up for historical archive purposes, but the me of today may 100% disagree with what I said then. I rarely edit posts after publishing them, but if I do, I usually leave a note in italics to mark the edit and the reason. If this post is particularly offensive or breaches someone's privacy, please contact me.
I am starting to hack on Mailman, per my plan for early 2015 -- and along the way, I'm also learning how to use Launchpad and Bazaar.
To quote maintainer Barry Warsaw's architectural overview, "GNU Mailman has been around since the early 1990s, when John Viega wrote the first version to connect fans with the nascent Dave Matthews Band, the members of which he was friends with in college." DAVE MATTHEWS BAND! I think this is amazing.
The developers just released 3.0 beta 5, Warsaw saying the 3.0 release is "really quite close now". As steering committee member Terri Oda explained and as Warsaw detailed when announcing the first beta of Mailman 3 in April 2014 (and in the architectural overview), the new suite has some cool new abstractions and a bunch of great new functionality.
Here are some pages I've found helpful while diving in. (Many are outdated; when the wiki conversion finishes up, I hope to do some gardening and updating.)
I've also enjoyed reading Warsaw's blog, and learning more about the weird ways of ISPs and email providers. As one exchange on the Mailman support list went:
This morning all of my subscribers with aol addresses were automatically unsubscribed from my list.
Why today? I thought all the DMARC issues had been resolved in the latest mailman version, and it's been 8 months now since the changes at AOL.
AOL has been having serious delivery problems. It's not just you.
My suggestion would be to sigh wearily and add the subscribers back in.
Mailman developers host their code, do code review, and track bugs on Launchpad, which Canonical runs.
I'm more familiar with Gerrit, Bugzilla, Trac, FogBugz, and GitHub, but I know Launchpad some. A few years ago, I wrote an overview of how Launchpad developers review each other's code, including the "merge proposal" concept (very roughly like a pull request; example). And I have used the bug tracker in the past -- it's similar to other bug trackers. So I have already been a tourist in Launchpad, which makes it easier to jump in as an expat. I'm still working on understanding the interaction of series, milestones, and releases with branches.
(I am very lucky in that I have a spouse who used to develop Launchpad itself (specifically the API) whom I can ask plaintively for help.)
You can create a test project on staging -- I will be doing this to learn Launchpad and Bazaar better. By the way, the RSA fingerprint (for when you upload or download code via the command line) changes, possibly every week when they wipe test data, and there's no place to verify that fingerprint.
Launchpad works best hand-in-hand with....
Canonical created Bazaar, a distributed version control system, several years back. I hadn't used it before starting to work on Mailman.
Again, I'm lucky -- Leonard worked in Bazaar for years (I am rather better than he is at git, so here's where the tables turn).
Some Bazaar resources (I have not looked at all these yet):
shelvewhich seems a bit like
I am overcoming the differences between Bazaar ("bzr") and Git, but slowly. For instance: in Git, when you clone a repository, you're also getting all the branches. In contrast, with Bazaar, you download each branch separately, and they go into separate directories. For instance, if you want the
bar branches of
testproj, you'd make local directories to house them, like:
$ mkdir testproj $ mkdir testproj/foo $ mkdir testproj/bar
Also, to oversimplify, when you do a merge in Bazaar, Bazaar just cares about merging the diffs -- you won't necessarily get all the commits (and commit messages) from the other branch grafted onto your branch. Or at least this is what I've run into -- I'm working on it!