AK's weblog

Dass mutt-ng so ziemlich eingeschlafen ist, wird mittlerweile jeder bemerkt haben, der mutt-ng selber verwendet. Tja, der Grund dafür ist, dass ich in Retrospektive betrachtet einfach nicht wusste, wie man das anzugehen hatte, um das ganze manageable zu halten. Insbesondere um das Mergen von Änderungen in upstream hab ich mir keine Gedanken gemacht, aber auch sonst wusste ich noch nicht so recht was über professionelles Patch-Management.

Die Probleme, die daraus resultieren, sind natürlich mannigfaltig: neue Features in mutt waren schwierig zu mergen, und das Tracken von Security Fixes ebenso problematisch. Irgendwann war dann ein Punkt erreicht, wo ich nicht mehr so recht motiviert war, da noch wirklich weiter dran zu arbeiten. Der damalige Stress in der Arbeit und schließlich das Bundesheer trugen ihr übriges dazu bei. Und auch die anderen Entwickler sahen die Probleme, die es bei mutt-ng gab.

Da aber mutt-ng doch einige sehr praktische Patches und Fixes enthält, die ihren Weg bis jetzt nicht in mutt gefunden haben, hab ich mich jetzt aufgerafft, und mir ein paar Gedanken gemacht, wie man denn das ganze besser machen kann, nachvollziehbarer, und vor allem so, dass Patches auch unproblematisch ihren Einzug in das offizielle mutt halten könnten. An Tools, um das Patch-Management zu unterstützen, hatte ich dazu transvn (welches auf Subversion aufbaut) und stgit (welches auf git aufbaut, das bei der Kernel-Entwicklung eingesetzt wird) evaluiert, mit keinem der beiden Tools war ich jedoch so wirklich zufrieden. Während sich transvn regelmäßig sein Repository zerschoss, und damit praktisch unbrauchbar war, hat git mit stgit doch den Vorteil, den Export und vor allem inkrementelle Updates aus CVS- und Subversion-Repositories zu unterstützen. So richtig zufrieden war ich damit jedoch nicht, weil es ja eine Bindung an ein bestimmtes Versionsverwaltungstool bedeutete. Und meine Anforderungen lagen nicht primär in der Versionsverwaltung, sondern im Patchmangement.

Mika hat mich dann freundlicherweise auf quilt verwiesen, ein Tool, dessen einziger Zweck Patchmanagement darstellt, unabhängig von jeder Versionsverwaltung, jedoch damit kombinierbar. Quilt verfolgt das Konzept eines Stacks, also ein Stapel von Patches. Man nimmt einen ungepatchten Sourcetree, sowie diesen Patchstapel, und kann einen Patch nach dem anderen, oder auch alle auf einmal hintereinander, applien. Wenn es ein Problem mit einem Patch gibt, so schreit quilt, und man kann dann manuell intervenieren, indem man z.B. den Patch durch einen aktuelleren ersetzt, oder den Patch trotzdem anwendet, und die fehlgeschlagenen Teile manuell einfügt. Damit kann es zwar zu Abhängigkeiten von Patches untereinander kommen, wenn diese etwa die gleichen Stellen oder sehr nahe beieinanderliegende Stellen im Source patchen. Praktisch hat sich dieses System jedoch bewährt, so schreibt eine wirkliche gute Einführung in quilt, die man bei SuSE findet, vom Extremfall, dass es zu einem Sourcetree wie dem Linux-Kernel mehr als tausend Patches zu verwalten gäbe, und dass das Ziel der Entwicklung von quilt es war, die SuSE-Kernelsourcen besser verwaltbar zu machen.

Nachdem ich also endlich die passenden Werkzeuge zur Verfügung hatte, hab ich mich gestern und heute hingesetzt, die Patches, die in mutt-ng eingeflossen sind, in aktuellen Versionen zu sammeln, sowie meine eigenen Änderungen aus mutt-ng zu extrahieren (wobei ich größtenteils auf frühere Versuche mit stgit zurückgreifen konnte), und mutt-ng neu zu bauen. Die Patches verwalte ich mich mit quilt, und das patches-Verzeichnis speichere ich in meinem Subversion-Repository. Mittlerweile ist dieser neuerliche Versuch schon soweit, dass ich sagen kann, dass ich ganz zufrieden bin mit der Funktionalität. An ein paar Stellen hakt es zwar noch, aber die hoffe ich in den nächsten Tagen beheben zu können, und das noch dazu in einer Form, die an die ursprünglichen Autoren zurückfließen können. Die derzeitigen Patches sind gegen das Release 1.5.12, bald werde ich jedoch versuchen, die Patches auf den CVS-Tree von mutt anzupassen.

Und so holt man sich die Patches und applied sie:
$ svn co http://bereshit.synflood.at/svn/mutt-patches/trunk/ mutt-patches
[...]
$ export PATCHES_DIR=`pwd`/mutt-patches/patches
$ cd $MUTTDIR
$ ln -s $PATCHES_DIR patches
$ quilt push -a
[...]
$ ./prepare
[...]
$ ./configure --your-favorite-options
[...]
$ make
Wie schon oben geschrieben, getestet ist das derzeit nur mit mutt 1.5.12.

So richtig öffentlich möchte ich das noch nicht stellen, da ich das ganze einerseits noch "runder" machen will und andererseits noch mehr Erfahrung im Patchmanagement sammeln will, insbesondere beim Einspielen von neuen Versionen der Patches.

Was mich im übrigens im Zuge der Arbeiten gestern und heute auch erstaunt hat, war, wieviel sich bei mutt mittlerweile getan hat. Header-Caching ist dazugekommen, und auch der GNUTLS-Patch wurde offenbar integriert. Immerhin diesen positiven Effekt hatte mutt-ng, nämlich die mutt-Entwicklergemeinde wachzurütteln, und klarzumachen, dass soviele praktische, jedoch nicht integrierte Features verfügbar sind. Einige weitere Patches, wie NNTP-Support oder die Sidebar, die wohl beliebtesten und am meisten verwendeten Features von mutt-ng, werden wohl nicht so schnell integriert werden. Insofern hat ein neuerlicher Anlauf in Sachen mutt-ng, diesmal mehr mit Fokus auf Patchsammlung und Integration ebendieser denn einem Fork, durchaus seine Berechtigung.

Today I spent a few hours of hacking on an IMAP mail client in Ruby which I codenamed "liam" (backwards for mail, haha, how funny). I based it on basically two libraries, namely Ruby's Net::IMAP, which provides a very complete (but a bit complicated) interface to IMAP, and Clifford's STFL, the Structured Terminal Forms Library, which is pretty new, but definitely the best ncurses widget library around.

The functionality is currently really simple: you start the program, it connects to your IMAP server, reads all available mailboxes from it, and lets the user decide which one to open. After selecting the right mailbox from the list, it is opened and the message envelopes from this mailbox are downloaded. Then, the user can again select the message he wants to view. Then, the message is downloaded and the raw message is presented to the user using the less(1) pager. The user can view this message. When he quits less, he is again presented with the list of messages in the mailbox. To return to the list of mailboxes, a simple press of the 'q' key is enough. From there, it is possible to select another mailbox, or to quit liam by again pressing 'q'.

This probably sounds pretty difficult, but it's extremely simple. To visualize this more efficiently, I prepared a simple screencast, which you can view here.

But what is my goal with this prototype? I don't know yet. It is definitely not here to replace mutt-ng (which is not dead yet, I'm currently preparing a "relaunch" since I now know my requirements much better than at the beginning of the project), but it's more a prototype to experiment on the future of terminal-based email clients. Sooner or later, mutt (and mutt-ng) will require a rewrite, and with this prototype I can find out what will be important for a new design, and where the stumbling blocks might be. Anyway, any feedback is welcome.

Update: more hacking on liam (including a new STFL widget), and a new screencast to demonstrate email viewing.