\documentclass[12pt]{article}
\title{Linda - A Debian package checker written in Python}
\author{Steve Kowalik $<$stevenk@debian.org$>$}
\usepackage{parskip}
\usepackage{titlesec}
\titleformat{\section}[frame]
  {\normalfont}
  {\filright
   \footnotesize
   \enspace Section \thesection\enspace}
  {8pt}
  {\Large\bfseries\filcenter}
\renewcommand{\familydefault}{\sfdefault}

\begin{document}
\maketitle

\section{The humble beginnings}

The reason I started writing Linda was the culimination of several events:
\begin{enumerate}
\item At the time, Lintian was unmaintained and, I felt, unmaintainable.
\item I wanted to learn Python.
\item I have an utterly unhealthy interest in Debian Policy
\end{enumerate}

\section{Development history of Linda}

First, there was Lisa. And it wasn't so good, actually. I still ended up showing it off at the mini-debconf at LCA '02 in Brisbane, and got many ideas, some of which are still in Linda today. The other thing I walked away from that talk was a new name as well. AJ informed me that Lisa is taken by one of the ladies of the katie suite, she handles NEW and BYHAND packages, and that it would be a good idea if I changed her name. AJ kindly suggested Linda, with the plus that it starts with 'lin', and the name has stuck. The rest of LCA '02 was spent re-writing the packaging (from scratch, I might add), and making her like the new name.

To embarass myself further, most of the early releases of Linda (up until 0.0.6 or so), I was still learning what I was doing, and to a lesser extent, learning Python, since my Python knowledge seems to have grown organically on it's own. I announced Linda to -devel on the 16th of March, 2002, and even made DWN issue \#12 of 2002 (20th March).

Linda 0.0.8, complete with bonehead error was uploaded to the archive on the 4th of June, 2002, and made it through NEW processing roughly six hours later.

The next big milestone was 0.0.13, which added support for checking .changes files themselves, as well as checking .udebs.

After that, the next milestone was 0.1.0, which I declared after 0.0.18, since I thought I had fixed enough bugs to warrant it.

The next thing of note I did is actually kind of fun, and was implemented in 0.1.3, which was multiple output formats. I don't even remember where I got the idea from, but they're in Linda now, and they aren't coming out.

Linda 0.1.6 actually included a linda.pot file. I didn't use l10n then, but I started shipping the .pot file fairly early.

In Linda 0.1.12, I (with James Troup and Matthias Klose), implemented a way to see if a binary indirectly links against two different versions of the same library. This was actually a great deal of fun, and actually got me respecting James a hell of lot more, just due to his arcane ELF knowledge.

The next milestone was 0.2.0, after I had rewrote enough to consider it good enough for the next .0 release. And of course, true to form, it took another 4 releases to get stable again.

In Linda 0.2.2, I finally purged the dependancy on python-apt by no longer using apt\_pkg for version comparsion, and ripping off DpkgVersion from Wichert. I have had to fix three or four neatly subtle bugs in it, but at least it doesn't cause Python to segfault on hppa.

In 0.2.6, I tried to do this whole l10n thing all by my own self, and starting parsing \$LANG and friends, and printing other language warnings and errors by looking up Description.parsed lang in the .desc file, like debconf does. Later, I figured out this was a \textbf{Bad Move}[tm].

In Linda 0.2.16, something quite amusing happened. I had rewritten level two source unpacking, which entirely unintentionally fixed a bug where you couldn't unpack a tarball with +'s in the filename. So, I'm reading through the bug report and saying ``But it does work?''

0.3.0 has been the biggest milestone to date. The changelog entry is 140 lines long, and I rewrote most of the core and helper libraries. Along with fixing a multiple of bugs. The most disruptive changes have been using gettext to print out the warnings and errors, which means gettext can just deal, and I don't have to care. .desc files were renamed to .data files, and I'm pondering getting rid of them anyway. I also wrote twelve parsers for Linda 0.3, the monster of which is RFC822Parser, which should be able to deal with any RFC822 style file. This is also where Collector first appeared, after being ripped out of unpack, and making it's code cleaner. And the biggest change is an automated testsuite for Linda. 

One of the things I've played with a lot while developing Linda has been Source Code Management tools. To date I'm currently using CVS, SVN and tla. I'm seriously considering switching to baz, but I'm uncertain if my brain can manually switch out of arch mode being things like 'tla make-log' and 'tla cat-log' instead of \textit{normal} things like 'svn ci' and 'svn log'.

\section{In-depth features of Linda 0.3}

Firstly, I'll start with the features that were introduced with Linda 0.3.

\begin{itemize}
\item A test suite: I know a test suite is a good idea, and I have lost count of the number of stupid bugs this has stopped me putting into a released version of Linda. The other side of the coin is that if I can't think of a situation, I can't test for it, which has happened a few times.

\item Actual localisation of the error messages: Ever tried running linda in a German locale? German is the most complete translation of warning and error messages that Linda has. Admitedly, there are a few issues with getting translators to work their magic on just over 500 strings.
\end{itemize}

\section{What can you do to help?}

In order of how much I will praise you and your skills in the changelog:

\begin{itemize}
\item Translations! Nothing makes my day like recieving an e-mail that teaches Linda a new language, or corrects her language skills.

\item Write patches! I have \textbf{never} recieved a patch for Linda that changes something non-trivial, and I would \textbf{love} to recieve such a patch via a bug report.

\item Test, and test and test some more. Another thing that makes my day is getting a well thought out bug report that points out where in the code a bug is hiding, and what I can do to reproduce said bug, and most importantly, \textbf{what package you pointed her at}, and which version.

\item An idea for a new test, or a what you consider a false positive for a test. Even if you're wrong, I'll still happily look at the code and see what it does, and maybe even rewrite it to be cleaner because of your suggestion.

\item Linda is mostly undocumented, or the document is written, but in my head, and not stored anywhere else. Yes, my backup strategy is absolutely shocking, too. I have made attempts at correcting this, but usually, I get bored or distracted, and my Grand Idea goes away. I would really like for Linda to have well-documented auto-generated (to some extent) documentation, but this may just be a pipe dream. So, some ideas on how to correct that.

\end{itemize}

\section{HOWTOs}

- How to write a test for Linda, in real-time.

\section{What is up and coming?}

At the moment, I have no hard and fast ideas for Linda 0.4.0. Does anyone have any that I can borrow?

The only ideas I am currently mulling over are using a lexer for parsing the multide of RFC822-style files, as well as profiling the hell out of Linda, and perhaps rewriting parts of her in C, since I would like to learn how to do that.

\end{document}
