Agile processes harness change for the customer's competitive advantage. Principles behind the Agile Manifesto

After two and a half years at Smoothwall, I'm moving on - Friday is my last day. Since I joined the development team, we have adopted Agile development, set up a pretty nifty Gerrit/Jenkins code review + integration system, and introduced dpkg for package management. Along the way, I helped with a bunch of important features for the business, like a ground-up rewrite of the web filter, and time-based browsing usage quotas. I will be starting at CV-Library on Monday, for a whole new set of challenges. They're based in Fleet, so I'll have an hour-long commute each way on the train. I've been assured by an expert in these matters that facilitating wage slavery is a comparatively more ethical pursuit than facilitating internet censorship. :) To make the commute somewhat more bearable, I'm moving house on Saturday. So far, the packing's going quite well...

---

---

---

Conrad Sanderson has released a new major version 3.0.0 of his excellent Armadillo C++ template library for linear algebra. A corresponding new release 0.3.0 of RcppArmadillo is now on CRAN. This follows four pre-releases of Armadillo which we packaged as before, but for reasons detailed in another post did not send to CRAN. All that said, here are the NEWS entries for all release since the last non-test release:

0.3.0   2012-04-10
    o   Upgraded to Armadillo release 3.0.0 "Antarctic Chilli Ranch"
          * added non-contiguous submatrix views
          * added shorthand for inverse: .i()
          * added hist() and histc()
          * faster repmat()
          * faster handling of submatrix views with one row or column 
          * faster generation of random numbers
          * faster element access in fixed size matrices
          * better detection of vector expressions by sum(), cumsum(),
            prod(), min(), max(), mean(), median(), stddev(), var() 
          * expressions X=A.i()*B and X=inv(A)*B are automatically converted
            to X=solve(A,B) 
0.2.40  2012-04-04
    o   Upgraded to Armadillo release 2.99.4 "Antarctic Chilli Ranch (Beta 4)"
          * fixes for handling expressions with fixed size matrices
0.2.39  2012-04-02
    o   Upgraded to Armadillo release 2.99.3 "Antarctic Chilli Ranch (Beta 3)"
          * faster repmat()
          * workarounds for braindead compilers (eg. Visual Studio)
0.2.38  2012-03-28
    o   Upgraded to Armadillo release 2.99.2 "Antarctic Chilli Ranch (Beta 2)"
          * added .i()
          * much faster handling of .col() and .row()
          * expressions X=A.i()*B and X=inv(A)*B are automatically converted
            to X=solve(A,B) 
0.2.37  2012-03-19
    o   Upgraded to Armadillo release 2.99.1 "Antarctic Chilli Ranch (Beta 1)"
          * added non-contiguous submatrix views
          * added hist() and histc()
          * faster handling of submatrix views
          * faster generation of random numbers
          * faster element access in fixed size matrices
          * better detection of vector expressions by sum(), cumsum(),
            prod(), min(), max(), mean(), median(), stddev(), var() 

Courtesy of CRANberries, there is also a diffstat report for 0.3.0 relative to 0.2.36 As always, more detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

Updated (2012-04-11): Now contains the final and correct pip install command. TL;DR: pip install django-money will give you a working set of Django fields that handle Money and Currency. Read below for how that happened. I began this Easter weekend trying to finish up one of my pet-projects and get it ready to publish. The goal of the website is to compare providers, of the same thing, from around the world. Representing prices is simple. A float will do if you are in a hurry. Except. When you need to perform calculations and you run into rounding errors. At that point you will likely discover the Decimal module. Which also works perfectly fine. And if you only ever deal in a single market that is fine. But across markets? That requires Money. Money is normally defined as a value and currency. Once you have both of those, you can then do cross-market comparison and upgrade you program to handle multi-currency easily. I hoped that I was not the only person who had realised this, so I started to look around. And I struck gold! I found Python Money. It even included appropriate Django fields as well. Unfortunately it had had no updates since 2008. . Worse it didn't work so well. I continued my search. I kept on looking and found Django Money. Even better. This separated out the Django support and the Python support. It turned out Jakewin's py-moneyed was actually a fork of Limist's py-moneyed. So I set about retrieving every fork and comparing them. <aside>Aside: There should be a git hubclone command which will add every fork of a project as an upstream so you can easily compare what has occurred and what has happened amongst them.</aside> It turns out that Jakewin's version was good, just out-of-date. It mentioned waiting until a pull request has been merged in to limist's version. Which had been done a while ago. And Jakewin's Django-money (djmoney) was nicely done too, unittests and all. It had just bitrotted compared to newer versions of Django (and South). I discovered there were a set of forks of django-money at github too. I analysed them all, and basically only jakewins's and reinbach's mattered. I created fixes for jakewins and reinbach's version. I also opened up on an issue asking limist's to tag and upload a new version of py-moneyed. I also got a response from limist and now you can do pip install py-moneyed and get a useful, working, version. And reinbach also responded and now you can do pip install django-money and get a working, usable, representation of Money within Django. It turned out to be a productive, if yak-shaving, weekend after all.

The RcppDE package required a bug-fix release. One of the tests compared results to those from the DEoptim package this is based upon, and these are no longer equal, leading the tests to fail. While I was at it, I finally committed a few more things that had piled up. Below are the corresponding ChangeLog entries

2012-04-08  Dirk Eddelbuettel  <edd>
        * DESCRIPTION: Release 0.1.1
        * tests/compTest.R: With the just-release DEoptim 2.2.0, results are
        no longer identical so we commented-out the stopifnot() comparison to
        not break any automated tests (as requested by the CRAN maintainers)
        * .Rbuildignore: Added a few more files which R CMD check does not
        want to see in the tarball
2011-03-07  Dirk Eddelbuettel  <edd>
        * src/evaluate.h: Also reflect '...' argument from R function we pass
        in, with thanks to Josh Ulrich for the one-line patch
        * R/DEoptim.R: No longer pass environment 'env' down
        * man/DEoptim.Rd: No longer document now unused 'env'
        * src/deoptim.cpp: Minor tweak to RcppArmadillo object creation

A few weeks have passed since SHOGUN has been accepted for Google Summer of Code 2012. Student application deadline was Easter Friday (April 6) and shogun received 48 proposals from 38 students. Some more detailed stats can be found in the figure below. This is a drastic drop compared with last year (about 60 students submitted 70 proposals). However, this drop can easily be explained: To even apply we required a small patch, which is a big hurdle.

1. One has to get shogun to compile (possibly only easy under debian; for cygwin/MacOSX you have to invest quite some time to even get all of its dependencies).
2. One has to become familiar with git, github and learn how to issue a pull request.
3. And finally understand enough of machine learning, shogun's source code to be able to fix a bug or implement some baseline machine learning method

Nevertheless, about a dozen of proposals didn't come with a patch (even though written on the instructions page that this is required) - an easy reject. In the end the quality of proposals increased a lot and we have many very strong candidates this year. Now we will have to wait to see how many slots we will receive before we can finally start the fun :-)

I ve been getting a lot of spam recently from people wanting to write guest posts or have their site included in a future links post. Guest Posts For guest posts the social convention for the planets which aggregate my blog seems to be that random guest posts are unacceptable. I could change my blog feed to have some posts excluded from the planet feeds but that s too much effort and I don t want random guest posts anyway. The only situations in which I will accept guest posts are when someone is writing what I might have written (IE they generally agree with me) or if they are a member of the free software community who doesn t have their own blog but has something relevant to say. Any applicant for a guest post who runs a business that is useless and/or evil IMHO (EG anything related to the TSA) is going to get rejected firmly. Any applicant who tells me that they can write on a wide variety of topics probably isn t capable of making me an offer that I would accept. Tell me that you can write about Linux programming or computer security and I ll be interested, but you have to provide links to your previous work. An application to write a guest post that starts with something like I liked your recent post at the above URL but I think you missed some important points, as I have some experience in that field I think I could write a guest post that would help educate your readers may be accepted. Probably the best thing to do however is to write comments on my blog, if you can write informative comments and offer to make a longer comment into a guest post then there s a good chance that I ll be interested. Generally though I will only offer the opportunity to write a guest post to someone who writes something really informative in private email or on a closed mailing list. If you can solve a technical problem about Linux that has me stumped then I will almost certainly be willing to accept a guest post about it! Links Posts There are many sites which consist of nothing but links to other sites. In the 90 s such sites were really useful but since the rise of Google their value has declined dramatically. As an aside when I ran an Internet Cafe in the 90 s I had every web browser start with the main page of my Hot Stuff list, the purpose of this was to increase the hit rate of my Squid cache by having most of the customers visit the same sites. Even back then I probably wouldn t have bothered if it wasn t for Squid hits. It must seem like an easy way to make money to create pages of links to articles with short summaries and then hope for advertising revenue, a domain sale, or the launch of some sort of profitable business once people start using the site. I wonder whether that ever works out for people. It doesn t seem like a good business model, doing something that requires little skill, which can be done by almost anyone, and which is done by many people. Maybe there are sweat-shops dedicated to this. Anyway my links posts are unlikely to ever link to any such links pages, I don t think that the people who read my blog want double indirection. I won t entirely rule out linking to a links page, but it would have to be of very high quality and related to something very technical about computers. Basically anyone who reads this should give up on the idea of submitting a links page to me, if it s good enough to make me break my policy of not linking to such things then I ll probably find it myself. Conclusion As a general rule if you want someone to publish your work then you need to look at what they are publishing and make sure that your work fits. With the recent requests for links and guest posts I ve been getting I have to wonder whether the people making the requests have even read my blog. That method of operating is unlikely to give any success at a blog that has any reasonable number of readers. I ll probably link to this from my about page or something. It might discourage some of the spammers. Related posts:

1. Link Within Good Things about LinkWithin For the last 10 weeks I ve...
2. Feedburner Item Link Clicks For a while I used the Item Link Clicks feature...
3. Can you run SE Linux on a Xen Guest? I was asked Can you run SELinux on a XEN...

Today I took that final step:

touch /srv/_global_/blacklisted/domains/aol.com

I remember, even a couple of years ago, I had friends who would mail me from their @aol.com email addresses. These days people have moved on. The two single biggest mail-providers I see in terms of spam are:

• @yahoo.com - 832 in the past nine days.
• @aol.com - 242 in the past nine days.

I'd like to drop @yahoo.com but I have some (misguided) friends who continue to use it to mail me. I might start dropping non-friend mails from that domain, but that's a bigger job. Yes, this is a dull entry. Sorry. My existing bathroom has been ripped out and turned into this as a stepping stone into its new incarnation. I'm trapped in my office. Dust almost everywhere. Noise everywhere else. ObQuote: "There can be no understanding between the hand and the brain unless the heart acts as mediator. " - Metropolis

I put up (with almost no filtration) the photos I took while visiting Brussels for FOSDEM in February. Most are from the Atomium.

Q: How much wood would a Richuck chuck if a Richuck could chuck wood? A: Quite a bit. The few times in the past when I was able to get my hands onto a tree or three, I thoroughly enjoyed turning them into firewood. It's good workout, you get fresh air, and you can actually see what you accomplished with your hands. Back then, I had access to a hatchet, a felling axe and a single wedge. Splitting anything larger than 20 or 30 cm in diameter was tedious work, though still enjoyable. Two weeks ago, I was presented with several cubic meters of spruce; log diameters ranging in between 10 and 50 cm, pre-cut to two meters in length. Plus, access to a chainsaw. Yay. After some research, I ordered two helicoidal splitting wedges (they turn themselves when driven into wood), a splitting axe and a splitting maul. The rest of the equipment handed to me is probably older than I am, but still working perfectly fine. You have to admire the simple yet efficient design of the cant hook. Something I could not find an English name for is the German Sapie, in itself loosely defined as "any tool you can use to pick up, turn, drag or otherwise move logs". There's a surprising variety of these tools, but then, moving wood around has been a necessity of life for millennia so people are bound to come up with good designs. Last weekend, the chainsaw wasn't running very smoothly or much at all, resulting in hours spent coaxing it to cut at least enough for some hacking (the wood, not the computer kind). Other than our chainsaw troubles, that weekend was very pleasant and I ended up splitting tons of logs. We had the chainsaw overhauled and resharpened during the week and picked it up again on Friday, planning to resume cutting early Saturday, a plan that was spoiled by torrential downpour and hail. In the afternoon, I started splitting some left-overs around the house and used a short break from the rain to head out into the woods to where the logs are piled. The place I chose for splitting is somewhat exposed and even though the mix of rain, sleet, snow, hail, and everything in between resumed soon enough turns out you simply stop caring at some point. While temperatures were around freezing, I ended up being drenched in sweat in no time at all. There is something primordial and deeply satisfying about simply working away at these logs, ending with piles and piles of firewood. Of course, using my favourite new toy, 4.6 kg of forged stainless steel fuck you, increased said satisfaction immensely. Between the two wedges and that maul, splitting any middle-European conifers is a breeze. Add in the splitting axe for slim trunks and splitting will take less than 60 seconds per cut, no matter how many branch knots or pockets of shock-absorbing partially decayed wood you encounter. If only I've had those tools a decade and a half ago... While I am feeling muscles I forgot I had, I am planning to pursue this new-found old hobby for at least the foreseeable future. Especially since I sourced more logs and a few trees, already.

If you are one of those brave souls chasing off spam from Debian mailing lists, you will probably get bored of clicking on the Spam radio buttons a lot of times, and will probably look for a quick shortcut. I submitted a patch in bug #640309, but as of today, it has not been applied yet. Waiting for the patch to be applied, I prepared a little Greasemonkey script called Debian Mass Spam that allows to mark every message as Unsure , Ham , Inappropriate , or Spam by clicking the correspondent key on the keyboard: Just press Z (for Unsure ), X (for Ham ), C (for Inappropriate ), or V (for Spam ), and you will see every radio button to change its status. I tested it on Chromium, Iceweasel (with xul-ext-greasemonkey package) and Epiphany (with epiphany-extensions package), and it seems to work properly. Too many words and no actions so far, go and kill some spam now!

I got into a discussion recently about what a Linux distribution actually is. To some people, a distro is just a convenient way of source of binaries from which to pick what you install, either on your own computer or when creating an embedded system, or some other specific kind of system. To others it's a way of life, and the realization of the ideals of software freedom. To yet others, a distro is an outdated concept that will go away in the near-ish future, to be replaced by ... something. Here's my take: a Linux distribution is defined by the following things:

• It's a specific, chosen set of upstream projects. The selection criteria vary wildly between distros, and may be based on things like purpose, quality, licenses, etc. Debian, for example, chooses pretty much everything that is free software, but a distro targeted at providing NAS devices would choose a much smaller set.
• It's a set of changes made to the upstream code, and specific configurations of the upstream code, in order make all the software work well together. For example, if the distro supports multiple mail transport agents, they might all need to be patched and configured to store incoming mail the same way by default.
• It's the tools, processes, policies, and workflows used to develop the distribution.
• It's the tools provided to the people using the distribution to install and manage their systems.
• It's the people and companies who develop the distribution and support its users, and their shared values and purpose. This may be a real community, or just the kind of community that exists as a web page.

Historically, there has been a lot of variation in all aspects mentioned above. Some of this variation may today be unnecessary. For example, it might be helpful for more distributions to share work on common tools, so that not everyone needs to re-invent and re-implement the same kinds of tools. However, my gut feeling is that due to the inherent interconnectedness of all things, it may be very difficult to have one set of tools to support well all workflows, policies, processes, and communities. The most important differentiating factors between the various distros are not the tools, but the community values, the perceived purpose of the distro, and the resultant criteria for choosing what to include and the workflow for developing the distro. Even when two distros use the same tools, there can be a lot of difference in the end result. Fedora and RHEL, for example, use a lot of the same infrastructure, but their purpose is entirely different. Debian and Ubuntu use mostly the same packages, even, and still there's a huge difference between the two distros: one aims at a high quality system based on free software, the other aims to support the business of one particular company. For this reason, there will always be a lot of Linux distributions around, and that is good.

I m back from one of the best experiences a father can have a whole day with two happy boys. I took Jacob (5) and Oliver (2) camping with me out by our creek. This was the first time we d camped there, and also the first time I d taken the boys camping without Terah along. So there were some unknowns, but it worked out great. When we got out there, I started to get the tents set up. The boys were interested, but pretty soon invented some games. A large nearby tree with plenty of low branches on its trunk became their locomotive, and certain sticks made the train go forward or backward, whistle, or ding its bell. This was good for quite some entertainment. Another nearby tree, near the bank of the creek, had some erosion near it. Combined with its roots, this made some natural steps. Jacob named some the enter steps and others the exit steps , and I sure heard about it if I walked the wrong way on the exit steps. We then gathered up sticks and the things we needed to build a campfire. We cooked up brats and zucchini. Although it was later than usual for supper, they loved it just the same. After that, we made smores for dessert another thing they loved. Then, one of the big highlights: sleeping in tents and sleeping bags. I had showed them the sleeping bags earlier, and they were excited to try them out. Morning was beautiful when the sun came out, it was shining right on the heavy dew on the ground, making the grass shine brightly. It s not every day that they get to start their morning slowly waking up by a warm fire. They were content to sit for quite awhile while I got things going for breakfast. It was chilly outside, so I helped them change clothes by the fire where. I then cooked them some scrambled eggs which, despite the lack of salt and pepper, seemed so much better than normal to the boys and then we went exploring. I took them to some areas with erosion, which Jacob called the big holes in the ground. It s really quite beautiful in spring, which this cellphone photo completely fails to capture. The boys loved climbing up and down these areas, some of which were quite tall. They discovered different kinds of rock on the way up and down, and with my help avoided discovering too much of the mud at the bottom. We hiked back to our camping spot through grass almost as tall as Oliver much to his delight and then after warming up by the fire for a bit, went off in the other direction. There is a grove of trees by the creek over there, which surprise became another train. Here are the boys explaining how it works. <iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="https://www.youtube.com/embed/43EcEK8F_ic?rel=0" width="560"></iframe> They helped pack things back up, too. Actually, it took some convincing to get Jacob to not pull up all the stakes for the tent before I was ready for them. Things didn t go perfectly, but then, they never do, and that was OK with everyone. Camping is an adventure, and it wouldn t be an adventure if you knew every detail beforehand. It is rare in life to be able to think that I have enough time to do anything the boys might want to do. Spend half an hour pretending a tree is a train sure, no problem. Today Oliver asked to go camping again, and was a bit disappointed when I didn t agree to go camping again right this minute, today. Jacob said, we had an EXCELLENT time and gave me hugs thinking about it. I have a lot of happy memories about the creek. We camped at the same spot where I went fishing or camped as a child. There have been family gatherings and even a birthday party out there. The boys and I have enjoyed a hike or a wagon ride to the area, but as I learned, nothing could possibly match the excitement of camping there. It is wonderful to add another happy memory of a time at the creek. And it s even better to see another generation of Goerzens discover that there s a lot of fun to be had down by the creek.

In the 3.x days of KDE, there were some wonderful applications. One of them I still admire, is kscope. Recently, I stumbled upon this blog entry and thought of sharing my living with kscope.The move from KDE 3 to KDE 4 was a big one. During that move, the kscope author decided to port kscope to a Qt only application. That is what we have as the latest kscope, 1.9x version. But, on personal taste, it is not as good as the 1.6x series.With no viable replacement to my knowledge, making use of kscope 1.6x on Debian (and Ubuntu) was the choice. Thanks to the way it is all packaged by the KDE, it is easy.Kscope depends on 2 packages for its functionlity: kdelibs4c2a and kate. kdelibs4c2a is unsupported, but for the dire needs, you live with it. The library can be easily pulled from the snapshot website, or just get the package from the old distribution URLs. The same goes for kate and kscope (1.6x)Install the kdelibs4c2a package.

16:55:27 rrs@champaran:~$ apt-cache policy kdelibs4c2a

kdelibs4c2a:

Installed: 4:3.5.10.dfsg.1-5

Candidate: 4:3.5.10.dfsg.1-5

Version table:

*** 4:3.5.10.dfsg.1-5 0

100 /var/lib/dpkg/status

Many of the SAN components in Debian have me involved. So I think out to give an update on what the state of SAN would be in Debian Wheezy. Open-iSCSI: Just uploaded a newer version to experimental which eventually will crawl into testing. It should fix all release goals for Wheezy. Please give it a good testiscsitarget: Same goes here. This one is already in testing. Please test. It has some bugs reported, all in needinfo, as they haven't been easily reproducible or reported complete.multipath-tools: It is in pretty good shape. Some minor bugs. But still, please test. :-)Open-FCoE: Being dependent on hardware, for which I couldn't manage resource commitment, this one is literally untested. It lies in testing, untested.LIO Target: The newest target implementation for Linux. It is also available in testing, has had some minor bugs reported by users, and fixed. If you use, or anticipate to use it in the Wheezy life cycle, now is the time to test.

apport just cleared the new queue and is now available in experimental. For those who do not know what apport is:

Debugging program crashes without any automated tools has been pretty time consuming and hard for both developers and users. Many program crashes remain unreported or unfixed because:

• Many crashes are not easily reproducible.

• End users do not know how to prepare a report that is really useful for developers, like building a package with debug symbols, operating gdb, etc.

• A considerable part of bug triage is spent with collecting relevant information about the crash itself, package versions, hardware architecture, operating system version, etc.
• There is no easy frontend which allow users to submit detailed problem reports.
• Existing solutions like bug-buddy or krash are specific to a particular desktop environment, are nontrivial to adapt to the needs of a distribution developer, do not work for crashes of background servers (like a database or an email server), and do not integrate well with existing debug packages that a distribution might provide.

Apport is a system which

• intercepts crashes right when they happen the first time,
• gathers potentially useful information about the crash and the OS environment,
• can be automatically invoked for unhandled exceptions in other programming languages (e. g. in Ubuntu this is done for Python),
• can be automatically invoked for other problems that can be automatically detected (e. g. Ubuntu automatically detects and reports package installation/upgrade failures from update-manager),
• presents a UI that informs the user about the crash and instructs them on how to proceed,
• and is able to file non-crash bug reports about software, so that developers still get information about package versions, OS version etc.

At this moment, it is quite broken. The crashes are not intercepted by update-notifier on my box. With it now in experimental, my intent is to slowly integrate it well with all dependent tools for Debian. It won't be ready for the Wheezy release, but hopefully for the one after that.On the Ubuntu side, Canonical hosts a retracing service that takes user reported core dumps and generates a usable backtrace. For Debian, my plan is to have a chroot kind interface, where in the user could opt-in to download all debug packages to generate a valid backtrace. This could go as the debian backend for apport in the future. On the bug reporting side, afaik, we do not have a web interface to lodge bugs. To report bugs (minus the core dumps), we will want a backend to submit it over email. The current apport report gathering tool is pretty good (if compared to other tools like reportbug), so here the low hanging fruit would be to just take the report and feed in email to our BTS server. For the eyes:

AoE is one of the protocols supported by Linux to access storage via network. It uses plain Ethernet for communication and includes a discovery mechanism to find all available targets. I use it to provide disk space to VMs running on different machines. Next step is to boot via AoE. It is no real problem to use AoE in running systems. However with some help it is even possible to actually boot disk-less machines via AoE. The PXE implementation iPXE provides the AoE support to actually boot from. I will describe the necessary parts.

I met Francesca in Debconf 11 in Banja Luka. If I recall correctly, it s Enrico Zini who introduced me to her, because she was the madamezou (her IRC nickname) who started to get involved in the publicity team. Since then and despite having a bachelor thesis to complete she got way more involved and even gained official responsibilities in the project. Before starting with the interview, I wanted to mention that Francesca is drafting a diversity statement for Debian I was expecting the discussions to go nowhere but she listened to all objections and managed to improve the text and build a consensus around it. Thank you for this and keep up the good work, Francesca! Rapha l: Who are you? Francesca: My name is Francesca, I m 30 and I studied Social Sciences. Currently I live in Italy but I m planning to go abroad (not a lot of jobs here for geeky social scientists). Apart for Debian and FLOSS world in general, I have unrestrained passions for chocolate; zombie movies; sci-fi; zombie books; knitting sewing crafting and DIY in general; zombie videogames; bicycles; pulling apart objects to look inside them; splatter B movies, David Foster Wallace s books, playing trumpet, and did I already mentioned zombies? Days are too short for all this stuff, but I try to do my best. Raphael: How did you start contributing to Debian? Francesca: Some years ago I was stuck in bed for literally some months, due to a grave series of migraine attacks. I wasn t able to do anything: no social life, no books or television. So, I decided to turn on the laptop and do something constructive with it: I was already a Debian user and it seemed quite logical to me to try to give back to the community. I am not a coder and I ve not studied Computer Science, so my first step was to join an Italian Debian on-line community (Debianizzati) and help with tutorials, users support, wiki management. In a couple of months I learnt many things: helping other users with their problems forces you to do lots of research! My first contributions to the Debian project were mostly translations of the main website. Translators are the perfect typos spotters: they work so precisely on the text to be translated that they finish to do a great QA job. This is how I ve started to contribute to the Debian website: with very simple things, fixing typos or wrong links or misplaced wml tags. I still remember my first commit to the website: the idea was to undercase some tags, but it ended up that I misplaced some of them and in addition I fixed them only in the English page and not on the translations as well. When after a couple of minutes, K re Thor Olsen a long time contributor of the team and now webmaster reverted my commit, I felt so stupid and full of shame. But, to my great surprise, no one treated me like an idiot for that error: Gerfried Fuchs, one of the guru of the team, replies me in a really helpful and polite way explaining what I did wrong and how to do things correctly. I think this episode was a turning point in my Debian life: there s this idea that Debian Developers are just a bunch of arrogant assholes and maybe it was true in the past, but for my experience they are not. Well, at least the ones I met and work with .

To my great surprise, no one treated me like an idiot for that error.

Since then, I joined the WWW team and helped them apply the shiny new design provided by Kalle S derman. A lot of work was done during the week immediately before the release of the new website. Oh that was a week! We worked night and day to have the new design ready for February 6th, and it was fantastic when we finally published it, simultaneously with the release of Squeeze. At the same time, I started to contribute more actively to the Debian Publicity team, not only translating news but also writing them. It can sound scary for a non native English speaker to write something from scratch in English, but you have to keep in mind that your text will be reviewed by native speakers before being published. And we have some fantastic reviewers in the English localisation team: particularly Justin B Rye, who is tireless in his effort and more recently Moray Allan. I think I m particularly lucky to work with all these people: there s a special mood in both Publicity and WWW team, which makes you feel happy to do things and at the same time pushes you to do more just because it s fun to work with them sharing jokes, ideas, rants, patches and hugs. Rapha l: I believe that you have been trough the new member process very quickly. You re now a Non-Uploading Debian Developer. How was the experience and what does this mean to you? Francesca: Becoming a Debian Developer was not so obvious for me, because I didn t need to be a DD for the work I do in Debian. For instance, I don t maintain packages, so I had no reasons to want to become a DD in order to have uploading rights. For a while I didn t really feel the necessity of being a DD. Luckily, some people started to pester me about it, asking me to apply for the NM process. I remember Martin Zobel-Helas doing this for an entire week every single day, and Gerfried Fuchs doing it as well. Suddenly, I realized that people I worked with felt that I deserved the DD status and that I simply had thought I didn t. As a non coder and a woman, there probably was a bit of impostor syndrome involved. Having people encouraging me, gave me more confidence and the desire to finally become a DD. And so I did. The process for non uploading DD is identical to the one to become an uploading DD, with one exception: in the second part of the process (named Tasks and Skills) instead of questions about how to create and maintain packages, there are questions about the non packaging work you usually do in Debian. The general resolution which created the possibility to become a non uploading DD gave us a chance to recognize the great effort of Debian contributors who work in various area (translations, documentation, artworks, etc.) that were not always considered as important as packaging efforts. And this is great because if you are a regular contributor, if you love Debian and you are committed to the project, there are no reasons to not be an official member of it. With regards to this, I like the metaphor used by Meike Reichle in her recent talk about the Debian Women Project (video recording here):

a Debian Developer status is a lot like a citizenship in a country that you re living in. If you live in a country and you don t have citizenship, you can find a job, buy a house, have a family [...] but if this country at any point in time decides to go into a direction that you don t like, there s nothing you can do about it. You are not in the position to make any change or to make any effect on that country: you just live there, but there s no way that you can excercise influence on the people who run this country.

Rapha l: You recently joined the Debian Press Team. What does it involve and how are you managing this new responsibility? Francesca: The Press Team is basically the armed wing of the Publicity Team: it handles announcements that need to be kept private until the release, moderate the debian-announce and debian-news mailing list and maintain contacts with press people from outside the project. The real job, so, is done within the Publicity Team. The most important part of our work is to write announcements and the newsletter: while the newsletter is published bi-weekly, the announcements need to be write in a shorter timeframe. Localization is really important in spreading Debian word, so we work closely with translators: both announcements and DPN are usually translated in four or five different languages. The publicity work could be stressful, as we have strict deadlines, we need to take quick decisions and often do last-minute changes. Personally, I like it: I work better under pressure. But I know that is sometimes difficult for contributors to accept that we can t debate endlessly on details, we have just to go on and do our best in a given timeframe.

The publicity work could be stressful, as we have strict deadlines, [ ]. Personally, I like it.

Raphael: You re one of the main editor behind the Debian Project News. What s the role and scope of this newsletter? Francesca: Debian Project News is our beloved newsletter, direct successor of the Debian Weekly News founded by Joey Hess in 1999 and later kept alive by Martin Schulze. In 2007, Debian Weekly News was discontinued but in 2008 the project was revived by Alexander Reichle Schmehl. The idea behind DPN is to provide our users an overview of what is happening inside and outside the project. As the core team of editors is formed by three people, the main problem is to be able to collect enough news from various sources: in this sense we are always glad when someone points us to interesting blogposts, mails and articles. DPN is also a good chance for non coders to contribute to Debian: propose news, write paragraphs and review the draft before the publication are quite easy tasks but very useful. English native speakers can do a proofread (as no one of the main editors is a native speaker) while others can always translate DPN in their native language. People who want to help us can take a look at our wiki page.

DPN is also a good chance for non coders to contribute to Debian.

Just yesterday I realized that since January we don t miss or delay an issue: so I d like to thank the fantastic team of editors, reviewers and translators who made it possible. The team is now working on another way of spreading Debian s message: a long-time project is finally becoming real. Stay tuned, surprise arriving! Raphael: You re trying to organize IRC training sessions but that doesn t seem to take off in Debian, while it s quite common in the Ubuntu community. How do you explain that? Francesca: I m not sure about it: both Debian users and contributors seemed to appreciate this initiative in the past. I was quite surprised by the amount of Debian members present during the various sessions and by the amount of interesting questions asked by the users. So the only reason I can think about is that I need to put more enthusiasm in convincing the teams to do it: they need more encouragement (or to be pestered more!). I, for myself, think that IRC training sessions are a great way to promote our work, to share our best practice, to talk about our project to a wider audience. And I ll sure try to organize more of them. Help, suggestions, ideas are really welcome! Raphael: If you could spend all your time on Debian, what would you work on? Francesca: There is a project I d like to give more love, but I always end up without the time to do it: the debian-community.org project. Back in 2007, Holger Levsen founded it with the aim of reducing the gap between Debian contributors and Debian users, giving all an opportunity to contribute, share ideas and more. The project was discontinued and I d really like to revive it: in these years various things have changed, but I think that the core idea of having a node to connect existing local communities is still good and doable. In Debian we don t have the wide and well articulated local infrastructure present in other distributions (Ubuntu, particularly, but also Fedora): even if I don t like too centralized structures, I think that a better connection between the project and local groups of users and on-line communities would be a step forward for the project. Being part of the Events Team, I m aware of how much we need to improve our communication with local groups. An example is the events organization: sometimes, Publicity and Events teams even don t know about regional Debian related events (like booth at conferences, workshops, talks, install parties, etc) and this is a shame because we could offer a lot of help in organizing and promoting local events. What we lack is better communication. And debian-community.org project could give us exactly this. Could be a cluster of local groups, a platform for events organization and even a useful resource for newbies who want to find a local group near them. I started some effort in this sense, sending a proposal about it, working on a census of Debian local groups. Any help is appreciated! I m really curious to see how many Debian communities (from all around the world and the web) are out there, and I d love to have members from these communities better connected with the Debian Project. Raphael: What s the biggest problem of Debian? Probably the bikeshedding feticism of almost all of us. It s the other side of the coin of Debian s commitment to technical excellence and our perfectionism, but sometimes it leads just to endless discussions about details, and it is a blocker for various initiatives. In Debian, you have to be really patient and in a way stubborn to push some changes. This is frustrating sometimes. On the other hand, I really appreciate how people take some times to think to each proposals, give some feedback and discuss about it: the process could be annoying, indeed, but the result is often an improvement of the initial proposal. Raphael: Is there someone in Debian that you admire for their contributions? Most of my teammates are simply brilliant and adorable and hard-working. But I have to admit that I particularly admire David Pr vot: beside being a webmaster he does a lot of things, from French translations to DPN editing. All his contributions have a great quality and he s able to push you always further in doing things and doing them better. He is a good example of how I d like to be as contributor: smart, tireless, friendly.

---

Thank you to Francesca for the time spent answering my questions. I hope you enjoyed reading her 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.

3 comments Liked this article? Click here. My blog is Flattr-enabled.

Falcon is a programming language which is not yet packaged for Debian. I saw that the ITP#460591 is owned by my Debian mentor and good friend Kartik Mistry. So I jumped in to help him finish this package. Ok enough of introduction now directly to point. We thought its better to base the Debian package on upstream Git repository itself so we can do snapshot release like Go Language package is doing. So in this post I'm going to give steps we used to do this and also guidelines on future packaging of Falcon.

1. First step we need to clone the upstream Falcon's git repo. Then duplicate *master* branch into *upstream* branch.

  git clone http://git.falconpl.org/falcon.git
  git checkout -b upstream
  

2. Now by staying on *upstream* branch we made it track the upstream's git repo using following commands

   git remote add upstream-falcon http://git.falconpl.org/falcon.git
   git branch --set-upstream upstream-falcon
   

3. We made the master branch point to origin which is our collab-maint git repository.

   git checkout master
   git remote set-url origin git.debian.org:/git/collab-maint/falconpl.git
   

4. Next is creating the pristine-tar branch so that it will be easy for us to build using *git-buildpackage* tools. We just took snapshot of upstream's head and created a tarball and then used *pristine-tar* utility to commit it. Then we tagged upstream version

   git checkout upstream
   git archive --format=tar HEAD   gzip -9 > ../falconpl_0.9.6.8-git20120403.orig.tar.gz
   git tag upstream/0.9.6.8-git20120403
   pristine-tar commit ../falconpl_0.9.6.8-git20120403.orig.tar.gz
   

5. And finally we copied **debian** directory from Ubuntu's falconpl package into our master branch and modified the debian changelog to match our new snapshot version. To release a new version all we need to do is follow step 4 and then additionally merge the upstream with master

So our repo is now in proper shape to be built using git-buildpackage. But we are left with many things to clean and fix. So things which are currently pending are

1. Make copyright file in Debian copyright format 1.0
2. Separate out each module falcon builds into separate package. Looks like Ubuntu doesn't install any of modules
3. Last but not the least upload it to Debian ( Kartik's task :-) )

Even though I'm packaging Falcon for Debian I'm not a Falcon programmer so if there are any Falcon programmer reading this post and want to help you are always welcome :-).