HyperKitty development used to happen on the fedorahosted.org platform, using the Bazaar version control system. The reason for this was that the rest of the Mailman developers were all using Bazaar, so it made sense for us to use it too in order to facilitate contributions.

But the fact is that the three main HyperKitty developers are much more at ease with Git than with Bazaar. I for one organized a migration from Subversion to Git in my previous job, where our SVN repositories had an “original” structure, and needed a lot of scripting to convert them to Git branches. I also integrated Git in our previous workflow and continuous integration server (Buildbot). That’s when I learned many of Git’s underlying tools (the plumbing commands), so I’m very familiar with it.

All in all, the move to Git makes sense now, and we chose the Github platform for hosting the code. It’s very popular and we hope it will limit the friction to contribute. Thanks to Git’s distributed nature we are not locked on Github, so the fact that it’s closed source is not too much of a problem for us. The ticketing system, the wiki and the mailing-lists stay on fedorahosted.org however, Github is only for code hosting.

Here are the new HyperKitty repositories: https://github.com/hyperkitty. Feel free to fork and contribute !

Well, long time no blog. But not as long as last time. Oh well.

There was FUDCon (Fedora Users and Developers Conference) in Paris this weekend. We had a great time, got some work done, but more importantly we got a chance to meet each other. I met Spot, my manager, and part of the team. And I met again the other French contributors to Fedora, which is always nice.

I tried to demo the project I’m working on, HyperKitty, but unfortunately I did it at the wrong time, so too few people were interested. This blog post will hopefully spread the word more widely. And who knows, maybe I’ll even take the habit of blogging more often. Sounds familiar ? D’uh.

Below are the slides I made for FUDCon, and some explanations to go with it. Just click to get to the next slide, and right-click to go back.

The current version of Mailman is 2.1, a version we have known to love (or hate every month) over the years. But Mailman 3 is in the works, and very close to release. We’re talking weeks here, a couple of months at most.

Mailman 3 is a complete redesign of the project. It focuses on a core server, which runs components, each running agents and passing email around.

You’ll find more info on Mailman 3’s architecture in its chapter of the AOSA book. There are many very interesting new features in this new version, including improvements in code quality and stability (which is a feature!).

The archiver which was shipped with Mailman 2.1, Pipermail, was stripped off, and an API was designed to enable any archiver to plug into Mailman3. It ships with plugins for The Mail Archive, MHonArc, and a basic archiver which stores the mails in maildirs. This is not how we, at the Fedora Project, think mailing-list would be best archived, viewed, and interacted with. So a few people in the Fedora Engineering Team started the HyperKitty project, working on the design, making prototypes, and recently hiring me to implement it. The links to the early design mockups can be found on the HyperKitty project page.

So, where are we ? I’ve worked a lot on the backend, called KittyStore, and I’ve only recently begun to touch the front-end, written in Python/Django. Fortunately, the work done by other contributors before me (Pingou, Toshio and Syst3mW0rm) was already very usable. A test server was setup with the latest developments, feel free to browse the imported archives there, but don’t be too surprised if it suddenly crashes on you, I may be uploading a new snapshot at the same time. Please report any bug you can find on the project’s Trac instance.

My aim is to have something stable with a basic feature set when Mailman 3 is released. I’ll implement the very nice features designed by Máirín later on. It’s going rather well, I’m fixing a few bugs and implementing the last necessary features such as importing from Pipermail and keeping Pipermail-compatible URL to transparently redirect to the new ones. I think we can meet the Mailman 3 release.

If you want to help, you can by installing it (and writing down the process!), testing it, importing from you own archive, testing the UI, reporting the bugs, etc. It’s a little early for new features, but if you’re motivated please go ahead ! They will probably be merged in a post-1.0 release however.

Je vous propose les diapositives d’une présentation que j’ai réalisée récemment, concernant les méthodes de développement permettant d’écrire un code facilement testable.