Photo by Wouter Verhelst
J rg is a very active contributor within Debian, and has been for a long time. This explains why he holds so many roles (FTPmaster and Debian Account Manager being the 2 most important ones) Better known as Ganneff (his IRC nick), he s not exactly the typical hacker. He has no beard and used to drink milk instead of beers.
Check out his interview to learn more about some of the numerous ways one can get involved in Debian, managing its infrastructure and without having to be a packager.
Raphael: Who are you?
J rg: My name is J rg Jaspert and I m 35 years old working for a small company
doing system administration and consulting work for our customers.
I m married for a little while now and sometime soon a little Ganneff
will be crawling out of my wife. (Whoever didn t think of the movie
Alien now is just boring).
Raphael: How did you start contributing to Debian?
J rg: I started using Debian somewhere around 2000, 2001. Before that I had
the misfortune to try SuSE and RedHat, both with a user experience that
let me fully understand why people think Linux is unusable. (Due to my
work I m in the unfortunate situation to have to use RedHat on two
machines. Funny how they are still utter crap and worse than bad toys).
And all of this lets get a Linux running here came up because I was
trying to find a replacement for my beloved OS/2 installation, which I
had for some years.
So after I got Debian installed, good old Potato, I got myself active on
our mailing lists, starting with the German user one.
A bit later I replied to a question if someone can help as staff for a
Debian booth somewhere. It was the most boring event I ever visited
(very nice orga, unfortunately no visitors), but I got a few important
things there:
- a signature from a DD on my key (Hi grisu),
- a discussion with an upstream author with some useful piece of software to package and
- an impression that this can be fun, if there are just some visitors for an event. So I tried again and did help as staff on a LinuxTag booth a while later.
The software I packaged, found me a sponsor and voila, maintainer I
was. Some more packages got added and at some point my sponsor turned
out to be my advocate. The NM process run around 2 months, and mid April
2002 I got THE MAIL.
Raphael: Some Debian developers believe that you have too many
responsibilities within Debian (DAM, FTPMaster, Debconf, Partners,
Planet Debian, Mirrors, ). Do you agree that it can be problematic,
and if yes, are you trying to scale down?
J rg: It s DebConf, tssk.
And yes, I do have some extra groups and roles. And you even only list
some, leaving out all I do outside Debian. But simply counting number of
roles is a plain stupid way to go. Way more interesting is how much work
is behind a role and how many other people are involved.
And looking at those you listed I don t see any I am a
SPOF. Let s look
at those you listed:
DAM: Here I did start out assisting James to get the huge backload
down which had accumulated over time.
Nowadays I am merely the one with the longest term as
DAM. Christoph Berg joined in April 2008 and Enrico Zini followed
during October 2010, both very active. Especially Enrico, lately
with the redesign of the NM webpages.
FTPMaster: The basic outline of the FTPMaster history is similar to the
DAM one. I joined as an assistant, after the oh-so-famous
Vancouver meeting in 2004. Together with Jeroen, we both then got
the backload down which had accumulated there. He did most of the
removals while I had a fun time cleaning up NEW. And we both
prepared patches for the codebase.
And in 2007, as the last action as DPL, Sam made me FTPMaster.
Since then I haven t been alone either. In fact we have much more
rotation in the team than ever before, which is a good thing.
Today we are 3 FTPMasters, 4 FTP Assistants and 1 Trainee.
Though we always like new blood and would welcome more volunteers.
DebConf: I am very far outside the central DebConf team. I am not even
a delegate here. Currently I am merely an admin, though there are
4 others with the same rights on the DebConf machines. I ve not
taken any extra jobs this year, nor will I. Probably for next year
again, but not 2012.
Planet: I am one of three again, but then Planet is mostly running
itself. Debian developers can just edit the config, cron is doing the work, not
much needed here. Occasional cleanups, every now and then a mail
to answer, done. In short: No real workload attached.
Mirrors: My main part here is the ftpsync scriptset. Which is a small
part of the actual work. The majority of it, like checking
mirrors, getting them to fix errors, etc. is done by Simon Paillard (and
since some time, Raphael Geissert is active there too, you might have heard
about his
http.debian.net).
Having said that, there is stuff I could have handled better or probably
faster. There always is. Right now I have 2 outstanding things I want to
do a (last) cleanup on and then give away.
Raphael: You got married last year. I know by experience that entertaining
a relationship and/or a family takes time. How do you manage to combine
this with your Debian involvement?
J rg: Oh well, I first met my wife at the International Conference on
OpenSource 2009 in Taiwan. So OpenSource, Debian and me being some tiny
wheel in the system wasn t entirely news to her. And in the time since
then she learned that there is much more behind when you are in a
community like Debian, instead of just doing it for work. Even better
that she met Debian people multiple times already, and knows with who I
am quarreling
Also, she is currently attending a language school having lots of
homework in the evening. Gives me time for Debian stuff.
How that turns out with the baby I have no idea yet. I do want to train
it to like pressing the M key, so little-Ganneff can deal with NEW all
on its own (M being Manual reject), but it might take a day or twenty
before it gets so far.
Raphael: Thanks to the continuous work of many new volunteers, the
NEW queue
is no longer a bottleneck. What are the next challenges for the FTPmaster
team?
J rg: Bad link, try
this one.
Also, no longer sounds like its recent. It s not, it s just that
people usually recognize the negative only and not the positive parts.
Well, there are a few challenges actually. The first one, even if it
sounds simple, is an ongoing one: We need Debian Developers willing to
do the work that is hidden behind those simple graphs.
Yes, we are currently having a great FTP Team doing a splendid work in
keeping that queue reasonably small this is a/THE sisyphean task per
excellence. There will always be something waiting for NEW, even if you
just cleaned the queue, you turn around and there is something else back
in already. Spreading this workload to more people helps not burning one
out.
So if one or more of the readers is interested, we always like new
volunteers. You simply need to be an uploading DD and have a bit of free
time. For the rest we do have training procedures in place.
Another one is getting the multi-archive stuff done. The goal is to
end up with ONE host for all our archives. One dak installation. But
separate overrides, trees, mirrors, policies and people (think RMs,
backports team, security team). While this is halfway easy to think of
in terms of merging backports into main it gets an interesting side
note when you think of merging security into main . The security
archive does have information that is limited to few people before
public release of a security announce, and so we must make sure our
database isn t leaking information. Or our filesystem layer handling. Or
logs. Etc. Especially as the database is synced in (near) realtime to a
DD accessible machine. And the filesystem data too, just a little less
often.
There is also a discussion about a good way to setup a PPA for Debian
service. We do have a very far developed proposal here how it should
work, and I really should do the finishing touches and get it to the
public. Might even get a GSoC project on it.
So far for some short to middle term goals. If you want to go really
long term, I do think that we should get to the point where we get rid
of the classical view of a source package being one (or more) tarballs
plus the Debian changes. Where a new version requires the full upload of
one or more of those parts of the source package.
I don t know exactly where it should end up. Sure, stuff like one
central DVCS, maintainers push there, the archive generates the source
tarballs and prepares the mirrors do sound good for a quick glance. But
there are lots of trouble and pitfalls and probably some dragons hidden
here.
Raphael: The Debian repositories are managed by DAK (Debian Archive Kit)
which is not packaged. Thus Debian users pick tools like reprepro to manage
their package repositories. Is that how things should be?
J rg: Oh, Mark Hymers wants to do a package again. More power to him if he does,
though yes, DAK is not exactly a quick-and-easy thing to install.
But nowadays it is a trillion times easier than the past thanks to
Mark s work people can now follow the instructions, scripts and
whatever they find inside the setup directory.
Still, it really depends on the archive size you are managing. A complex
tool like dak does not make sense for someone who wants to publish one
or a dozen of his own packages somewhere. Thats just like doing a finger
amputation with a chainsaw it certainly works and is fun for the one
with the chainsaw but you probably end up a little overdoing it.
I myself am using dpkg-scan[packages sources] from a shell script but
also mini-dinstall in places (never got friend with reprepro when I
looked at it). Works, and for the few dozen packages those places manage
it is more than enough.
Also, using dak forces you into some ways of behaviour that are just
what Debian wants but might not be what a user wants. Like inability
to overwrite an existing file. One of the reasons why mentors.debian.net
won t work with dak. Or the use of a postgres database. Or that of gpg.
Sure, if you end up having more than just a dozen packages, if you have
many suites and also movement between them, then dak is sure a thing to
look at.
And how should things be : however the user and admins of that certain
install of reprepro, mini-dinstall, dak, whatever want it. This is not
one-tool-for-all land
Raphael: What is the role of Debian Account Managers (DAM)? Do you believe
that DAMs have a responsibility to shape Debian by defining limits
in terms of who can join and what can be done within Debian?
J rg: Quote from
https://lists.debian.org/debian-devel-announce/2010/10/msg00010.html:
The Debian Account Managers (DAM) are responsible for maintaining the
list of members of the Debian Project, also known as Debian
Developers. DAMs are authoritative in deciding who is a member of the
Debian Project and can take subsequent actions such as approving and
expelling Project members.
Now, aside from this quote, my OWN PERSONAL OPINION, without wearing
anything even vaguely resembling a DAM hat: DAM is the one post that is
entitled to decide who is a member or not. Usually that is in the way of
joining (or not), which is simple enough. But every now and then this
also means acting on a request to do something about whatever behaviour
of a Debian Project member. I hate that (and i think one can easily
replace I with WE there). But it s our job.
We usually aren t quick about it. And we don t act on our own initiative
when we do, we always have (numerous) other DDs
complain/appeal/talk/whatever to us first. The expulsion procedure ,
luckily not invoked that often, does guarantee a slow process and lots
of input from others.
Are we the best for it? Probably not, we are just some people out of a
thousand who happen to have a very similar hobby Debian. We aren t
trained in dealing with the situations that can come up.
But we are THE role inside Debian that is empowered to make such
decisions, so naturally it ends up with us.
Raphael: You did a lot of things for Debian over the years. What did
bring you the most joy? Are there things that you re still bitter about?
J rg: The most joy? Hrm, without being involved in Debian and SPI I would
never have met my wife.
Or my current job.
Or a GR against me. Not many running around with that badge, though I m
still missing my own personal Serious problems with Mr. Jaspert
thread. Bad you all.
Or visited so many places. Think of all the DebConfs, QA meetings, BSPs
and whatever events.
Or met so many people.
Or learned so many things I would never even have come near without being DD.
Raphael: Is there someone in Debian that you admire for their contributions?
J rg: Yes.
Thank you to J rg for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that older interviews are indexed on
wiki.debian.org/PeopleBehindDebian.
Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.
One comment Liked this article? Click here. My blog is Flattr-enabled.
A new minor release 0.4.21 of RQuantLib
arrived at CRAN this afternoon,
and has already been uploaded to Debian as well.
QuantLib is a rather
comprehensice free/open-source library for quantitative
finance. RQuantLib
connects (some parts of) it to the R environment and language, and has
been part of CRAN for more than
twenty years (!!) as it was one of the first packages I uploaded
there.
This release of RQuantLib
benefits from some kind attention that Jeroen has been paying to how we
build (especially at CRAN) on
both macOS and Windows. So the build processes are a little better now,
and no internal code changed. QuantLib 1.33 built unchanged.
This is the report for the 
The following contributors got their Debian Developer accounts in the last two months:
Data is from 
Particularly noteworthy is the addition of support for intra-daily times in 
I *did* some hacking at DebConf, as usual. For once, I had no TODO
list: after all, I never complete these, so why make one?
Still, I participated to discussions around samba packaging, mostly
animated by Ivo De Decker and I think we're making good progress
towards samba 4.x packages. The road is long, quite complicated, but
we now have a stronger team, with a very active Ivo, Jeroen Dekkers
who officially joined, Steve Langasek who still cherishes one of his
pet packages (and even branched in our git with the Ubuntu packages).
Great work and thanks to Ivo for pushing this forward.
I also worked quite actively on the migration of fonts packages to git
(I now reached the point where I'm more comfortable with git than SVN,
yes, everything can happen). These packages were modernized at the
same time and checked for new upstream versions (I have to say that
few of these fonts had new upstream versions, indeed). We
unfortunately found no time to have a good font BoF in Vaumarcus,
indeed...but I'm not sure we would have many things to say. The work
is done and done well, in this team.
Some progress was made, also, for restoring a working "monolithic"
build of D-I. This build gathers together all udebs from unstable,
which means it offers a D-I image that uses ALL udebs from
nustable.....which is not the default of other images. This would be
very helpful for translators who want to check their work as soon as
possible. In the future, with a Jenkins task that would build each
package at each commit and then build a monolithic image, we could
have a way to provide a tes snapshot of D-I git repos.....which could
help catching more bugs (or more of my stupid mistakes).
So, in general, I consider this a quite successful DebConf when it
comes at "real" production.