It's about time that Rapha l is interviewed in the "People behind Debian" series he initiated on his blog. Indeed, when he interviews people, Rapha l asks about other people they could suggest for next interviews. So, during mine, I suggested him to be a next "victim". As he couldn't interview himself, I volunteered for this. As you'll see below, Rapha l (who's a friend of mine as I'm a friend of his) likes to speak and that shows in the length of his answers :-) but you always know more about Debian when reading his blog posts, books, mails, etc. I personnally think that he is among the best promoters of the project for years and it was a pleasure for me to conduct this interview. My questions are in bold, the rest is by Rapha l. Who are you? Hi, Rapha l Hertzog, I'm a 32 years old French Debian developer who is married and who has a 2-year old son. I'm running my own company (Freexian) since 2005, I started it 3 years after the end of my computer science studies. I'm also a very proud author of the Cahier de l'Admin Debian, a French book about Debian. You often wrote about your attempts to make your living partly, if not completely, out of your Debian work. Can you describe the way you're trying to do this? My first try has been with Freexian. I always advertised this company as being specialized in Debian GNU/Linux. While Freexian is successful enough to provide me a decent income, I'm not really satisfied with the result because very few of my contracts are about improving Debian. I use Debian daily for the benefit of my customers, writing new customer specific (embedded) software, deploying a service on Debian servers, etc. But except for the occasional bugfix, all this work does not improve Debian (the only exception has been the dpkg multiarch implementation work sponsored by Linaro). The positive side is that I don't need to fill my entire schedule to earn enough money to live. So I'm regularly taking some days off work to be able to contribute to Debian. This is a freedom that I enjoy... My French book has also been a bestseller and depending on the years the royalties represented between 1 and 2 months of supplementary time that I can spend on Debian (that is between 2000 and 4000 EUR of income). Now since last year, I decided to actively work towards my goal of making a living out of my Debian work. I want to build on what has been most successful for me up to now, that is my book. My strategy has been to build an audience around my blog: with a direct contact with my readers I have the opportunity to sell e-books, and without any intermediary taking the biggest part of the price, I don't need a very large audience to be successful. I have also been experiencing micro-donations with Flattr, people who are enjoying my articles on my blog can use it to give a few cents for each article they find useful. With a large enough userbase, this could fund free documentation and would avoid the need for commercial e-books but we're not there currently and I don't know if it will ever reach the critical mass. Last but not least, I'm soliciting donations for my Debian work on the sidebar of my blog, and I have the chance to a have a few (regular) donators. You're a proud father since last year. How do you manage your commitment to the project with your family life? There are few things that I put above Debian in my life, but my family certainly is. I try to handle most of my Debian duties during work hours so that I can spend time with my family on evenings and during week-ends but in truth I never really disconnect from Debian. It happens quite often that I say to my wife I'll come in a few minutes, let me finish this and then I end up responding to a Debian mail, or an IRC query and take 30 minutes instead of the 5 expected ones. I try hard to avoid this but it's difficult. Luckily for me, my wife is very supportive of my Debian involvement and knows me well... By the way my wife is using Debian on her computer, and my son has already played with DoudouLinux (a Debian derivative!). Have you already been accused of self-promotion in your writings? If that would ever happen, what would you answer to that? Yes, more than once. I am proud of what I do for Debian, I enjoy sharing the result of my work. Because of this, some people believe that I'm selfish and egocentric. And this has somewhat increased since I have been soliciting donations: for me it's important to be transparent towards donators so that they see what I really do for Debian. But some people have the feeling that I'm getting undeserved attention and that I bring everything towards my own person. On the other side, as an author, I'm a public figure who is definitely seeking some attention... I don't have any miraculous answer, we are a large and diverse community, it's next to impossible to please everybody. I listen to all the concerns that people bring forward, I take them into account as much as possible, in particular when I believe they are reasonable/well justified, or when they come from people that I highly respect. But sometimes I have to plainly ignore them too... in particular when they are trying to impose their own political view on a topic that's not directly related to the only value that we all share: the social contract. Contributing to Debian is a challenge, we all have to make efforts to put aside our differences and to concentrate on the work that brings us closer to the best free software operating system ever built. You recently launched a campaign to free out the soon-to-be-published "Debian Administrator Handbook", an English version of your well-known book about Debian in French. Can you tell us more about this project? My French book has been very successful at helping people to get started with Debian, and like I already explained, it was also effective to fund a part of my Debian work. So I wanted to make it available world-wide by publishing an English translation of it. I tried to find an English-speaking editor willing to take on the challenge but I found none interested. Not put off by a setback, Roland (my co-author) and I decided to negotiate with our French editor Eyrolles to recuperate the necessary rights to translate the book into English. Handling everything ourselves represents a lot of work, but it also means that we have the freedom required to decide of the license of the resulting book. We would love to see it under a license compatible with the Debian Free Software Guidelines. But at the same time we firmly believe that we deserve a reasonable monetary compensation for the work on the book, so we conditioned its liberation to a predefined amount of money (25 K ) in what we call the "liberation fund". And since we wanted to be sure that we would have the required means to complete the translation, we used a crowfunding platform to seek support of people interested by the book. With such a platform you're only debited if the minimal requested amount is reached. Anyone can participate, pre-order the book and/or put some money in the liberation fund. As of today, we already reached the minimal funding goal (15 K ) so the book translation will happen. But the liberation target has not yet been reached so we don't know yet if the book will be free from the start... you can follow the progress right on the fundraising page or on the website dedicated to the book. PS: If you want to contribute to this project and also make a donation to Debian at the same time, you should check out this page. You're one of the main developers of dpkg, a critical tool for Debian systems. Can you tell us more about the current development challenges it is facing? What will be the new dpkg features for wheezy? The current challenges are not really technical. dpkg is a relatively mature piece of software and it will continue to work for the foreseeable future without needing much maintenance work. The real challenge is trying to setup a healthy developement community around it so that we can keep tackling new interesting problems (there are many listed in the roadmap and in the 225 wishlist bugs). There is a real problem of leadership and communication in the current team. We used to be three, and we're only two nowadays. Guillem is the legitimate leader since he's involved in dpkg's developement since early 2006 while I joined only in late 2007. But in the last 4 years, we did not manage to recruit anyone else on the team. Some persons tried to contribute significant new features (like Sean Finney with a rework of the way we handle configuration files) but they gave up frustrated after a while because we did not manage to review their work (and discuss the design) in any reasonable timeframe. Another famous case is Ian Jackson with his trigger work. His work got merged, but so late that in the mean time he blew up while trying to hijack the maintenance of dpkg. For a long time I was concentrating my work on the Perl part of dpkg (aka dpkg-dev mainly), so I did not feel qualified to review and merge work related to the C part and I was just a worried observator of this situation. I tried to improve it by setting up some basic review infrastructure, it should have brought some lisibility to the status of each change left to be reviewed... but it has not been used and it changed nothing. Over the years, I became much more interested in the C part. My first big contribution in C has been the rewrite of update-alternatives (from Perl to C). I made other small changes in between, but at the start of this year I had this great opportunity to work on the multiarch implementation (FYI, multiarch is the possibility to mix packages from several architectures on a single system). This really forced me to jump into the C codebase and learn a lot about how dpkg is implemented. Thanks to this I have been able to tackle other small projects (like the improved triggers). This would be all great if my multiarch work was already merged, but it's not. It's a large work, I do not mind waiting a bit in particular since Guillem is a highly skilled C programmer. His sharp analysis of new designs are invaluable, when he reviews code he always finds something to improve. I learnt a lot just by reviewing the code he wrote over the years. That said I have been waiting since April without almost no updates from him. With the release team asking us to hurry up, the situation is getting somewhat strained as I really want to see multiarch in Wheezy and I do not really want to short-circuit Guillem. Hum, I may have drifted a bit from your original question... what great new features can people expect? Well multiarch is supposed to be the big new feature, apart from that there aren't many things that matter to the end users. But there are already quite a few changes that are of interest to package maintainers (like hardened build flags, source package improvements, improved triggers, ). What's the biggest problem of Debian? Manicheism and a tendency to quickly polarize the discussions. In reality, there are very few situations where everything is all good or all bad. Ever since I have read The 7 Habits of Highly Effective People I try hard to put into practice the habits of interdependence . Instead of having only my point of view in mind, I try to understand the motivations from the other party ( Seek First to Understand, Then to be Understood ) in order to be able to put forward solutions acceptable to both parties ( Think Win-Win ). I highly recommend this book to anyone. And I invite everybody to at least try to follow those simple advices. Is there someone in Debian you admire for their contributions? There are many and I can't give an exhaustive list... here are some that I would like to highlight (in no particular order):

• Niels Thykier for the work he puts into Lintian, and his recent work on a britney test-suite (the software that creates testing out of unstable);
• Joachim Breitner for his britney reimplementation using a SAT solver;
• Adam D. Barrat for his work on britney2;
• All the release team members who take care of an endless stream of transitions;
• Christoph Berg for his continuous work over the years on various QA infrastructure (DDPO, Mole, );
• Enrico Zini for the way he helped reform the New Member process without any big disruption;
• Russ Allbery for his Debian Policy work and for being a model in terms of how we should interact on Debian mailing lists;
• Stefano Zacchiroli for being the most active leader that I have ever seen, and for the way he tries to steer important discussions to a constructive conclusion.
• etc.

Most of those people are working on improving Debian's infrastructure so that we can all be more effective and do an even better work. This kind of work is not always very visible but it's crucial to Debian's future. Thank you to Rapha l for the time spent answering my questions. I hope you enjoyed reading his answers as I did. And, anyway, it was fun to just play the game "the other way".

A while ago I've been interviewed for a forthcoming article in the LinuxUser magazine on the topic of why there are so many Debian derivatives and on the potential impact, on them, of the (potential) advent of the so called "Debian Rolling" experiment. Below you can find my take on those topics. Questions are by Ferdinand Thommes, who has been involved in various Debian derivatives, including the forthcoming Siduction.

---

1.) Why do you think people base distributions on Debian? Looking at how many there is, since Corel and Libranet set sail in 1999, there must be a reason why, for one, people fork Debian in the first place, and secondly, why they choose Debian to do so and not some other distribution.

There are always advantages in creating a so called "derivative" distribution with respect to creating one from scratch. The main one is the possibility of reusing the packaging work which is already done in the "upstream" distro, focusing derivatives' efforts on customization, usually with clear target public in mind. Debian pushes most of those advantages (for derivatives) at their extremes.

• The Debian archive is huge (about 30'000 packages with Squeeze), meaning that the amount of packaging work that can be reused is similarly huge.
• Debian has a long history and a well established community, which reduces the risk of "betting" the efforts of derivatives on a distro that might disappear anytime soon.
• Debian is well known for its obsession with package quality, meaning that the risk of trusting pre-existing packages is greatly reduced, and that package behavior is on average very dependable as well as documented in standard documents such as the Debian Policy
• Debian is also well known for its obsession with licensing, at the point of being considered by many one of the authoritative sources for deciding what constitutes Free Software and what does not. For derivatives that implies that they do not need to worry---as long as they trust Debian, of course---neither about legal redistribution risks nor about software freedom claims on their distro.

But there are also a couple of "political" reasons for basing derivatives on Debian. One is quite subtle and applies mostly to commercial distributions. If you are designing one such commercial distro, you have to be based on an independent distro with no commercial interests, lest risking that petty (technical or otherwise) choices might be made just to undermine your business. Among "popular" GNU/Linux distros, Debian is essentially the only one which is both volunteer-based and not ascribable to any specific company. The last reason why I think many derivatives are based on Debian is our vocation to universality. Since we are not targeting any specific public, but rather trying to provide an operating system suitable for several different use cases (e.g. the tasks supported by the Debian installer or the choice of Debian Pure Blends), we offer an ideal starting point for those who are going to have customization as their main business.

2.) What could be the benefits for Debian and for its Derivates, if the discussions about a second Debian Release based on the Testing branch really come to be reality?

We are considering the possibility of adding a new Debian suite which is "rolling" like Testing, in the sense that new software releases flow in regularly rather than only at periodic bumps corresponding to major distribution releases. There seem to be user demand for that and I personally believe that such a scheme could address the needs of both advanced desktop users and of developers, which are now strand to mix and match Debian suites ending up using package combinations which benefit, as a whole, of very little quality check. The main issues to face to get there is how to make sure that adding such a suite would not get in the way of preparing high quality Stable releases, in terms of quality control, developer focus, etc. Note that such a hypothetical "rolling" suite needs does not necessarily need to be based on Debian Testing, although that is a good starting point. The reason why it's not a good endpoint is that Testing has been created (circa 2000), and is still used, as an internal tool to prepare the forthcoming Debian Stable release. As such, it is not entirely suitable for final user consumption. For instance, during the Debian "freeze" period the flow of new software releases that reach Testing is greatly reduced up to stopping completely just before the release of a new Debian Stable. I've been told that users of testing-based (derivative) rolling releases regularly complain about this aspect during Debian freezes, which is not surprising. The main advantage for derivatives which are already offering a Debian-based "rolling" release will then be the possibility of basing their work on a suite less bound to the life cycle of Debian Stable than Testing is at present. On the converse side, that would also mean that derivatives will need to differentiate more from Debian than by just saying they are "rolling", which is a good thing: differences among distros are healthy and drive innovation. With those derivatives, on the other hand, which will recognize their goals as being aligned with Debian's goals---Debian Stable today, maybe Debian "rolling" tomorrow---we will be happy to join efforts.

Even though Enrico is not smiling on this picture, he s one of the friendliest Debian person that I know. I always enjoy his presentations because he can t refrain from inserting jokes or other funny tricks. That said he s serious too, there s lots of good stuff that he has developed over the years (starting with Debtags) and he has put a lot of effort in reforming the New Maintainer process. Read on to learn more about his various projects. Raphael: Who are you? Enrico: Hi, I m Enrico Zini, a DD from Italy. I m 35 and I work as a freelance Free Software developer. One of my historical roles in Debian is taking care of Debtags, but that is not all I do: my paid work led me to write and maintain some weather forecast related software in Debian, and recently I gained a Front Desk hat, and then a DAM hat. Raphael: How did you start contributing to Debian? Enrico: It was 2001, I was at uni, I was using Debian. At some point I wanted to learn packaging so I read through the whole Policy from top to bottom. Then I thought: why package only for myself? . There were many DDs at my uni, and it only seemed natural to me to join Debian as well. Evidently this was also natural for Zack [Note from editor: Stefano Zacchiroli], who had become DD 6 months earlier and didn t hesitate to advocate me. I found the Policy and the Developer s Reference to be very interesting things to read, and I welcomed my AM s questions as an excuse to learn more. I completely understand those people who have fun trying to answer all the questions in the NM templates while they wait for an AM. With my super DAM powers I can see that my AM report was submitted on October 16, 2001 by my AM Martin Michlmayr, and that James Troup created my account 9 days later, on October 25. Raphael: You have a special interest in the New Maintainer (NM) Process since you are a Debian Account Manager (DAM) and a member of the NM Frontdesk. Thanks to your work the process is much less academic/bureaucratic than it used to be. Can you remember us the main changes? Enrico: One of the first things I noticed when I become a Front Desk member is that there was a tendency to advocate people too early, thinking by the time they ll get an AM, they ll know enough . Unfortunately, this didn t always work, and once the real NM process started it would turn into a very long and demotivating experience both for the applicant and for the AM. So we tried raising the bar on advocacies, and that seems to have helped a lot. If people join NM when they are ready, it means that NM is quick and painless both for them and their AMs, who are therefore able to process more applicants. We also did a rather radical cleanup of the NM templates , which are a repository of questions that Application Managers can ask to their applicants. We realized that AMs were just sending the whole templates to their applicants, so we moved all non-essential questions to separate files, to drastically reduce the amounts of questions that are asked by default. Other improvements in the NM process came from other parts of Debian: nowadays there are lots of ways to learn and gradually gain experience and reputation inside the project before joining NM, which means that we get many candidates who we can process quickly. For example, packages can now be uploaded via sponsors, and the Mentors project helps new contributors to find sponsors and get their first packages reviewed. Then one can now become Debian Maintainer and take full responsibility of their own packages, gaining experience and reputation. The idea of working in teams also helped: big teams like the Perl, Python, KDE, Ocaml, Haskell teams (and many more) are excellent entry points for people who have something to package. But Debian is not just for packagers, and one could join teams like the Website team, the Press and Publicity team, the Events and Merchandise team or their local translation team. Becoming DDs the non-uploading way is not just for non-technical people: one could enjoy programming but not packaging. An interesting way to get involved in that way is to help writing or maintaining some of the many Debian services. Note that I m not suggesting this as a way to learn how to program, but as a way to get involved in Debian by writing code. Finally, we started to appreciate the importance of having people activities in Debian explicitly visible, which means that the more obviously good work one has done in Debian, the less questions we need to ask. Jan Dittberner s DDPortfolio is an excellent resource for AMs and Front Desk, and I m maintaining a service called minechangelogs that for people who have done lots of work in Debian is able to fully replace the Tasks&Skills parts of the NM process. Raphael: What are your plans for Debian Wheezy? Enrico: For Wheezy I hope to be able to streamline and simplify Debtags a bit more. At Debconf11 I had a conversation with FTP-masters on how to make some tags more official, and I now have to work a bit more on that. I d also like to considerably downsize the codebase behind the debtags package, now that its job is quite clear and I don t need to experiment with fancy features the way I did in the past. I have to say that I enjoy programming more than I enjoy packaging, so most of my plans in Debian are not tied to releases. For example, I d like to finish and deploy the new NM website codebase soon: it would mean to have a codebase that s much easier to maintain, and in which it s much easier to implement new features. I d also like to design a way to allow maintainers to review the tag submission to their own packages instead of having to wait for me or David Paleino to do a regular review of all the submissions. Finally, I d like to promote the usage of apt-xapian-index in more cutting-edge packaging applications. And to design a way to maintain up to date popcon information in one s local index. And improve and promote those services that I maintain, and I tend to often have ideas for new ones. Raphael: If you could spend all your time on Debian, what would you work on? Enrico: If I could spend all my time on Debian, I would do a lot of software development: I love doing software development, but most of my development energy is spent on my paid work. I guess I would start my all your time in Debian by taking better care of the things that I m already doing, and by promoting them better so that I wouldn t end up being the only person maintaining them. After that, however, I reckon that I do have a tendency of noticing new, interesting problems in need(?) of a solution, and I guess I would end up wildly experimenting new ideas in Debian much like a victorian mad scientist. Which reminds me that I most definitely need minions! Where can I find minions? Raphael: You re the author of the Debian Community Guidelines. I have always felt that this document should be more broadly advertised. For example by integrating it in the Developer s Reference. What do you think? Enrico: The DCG was really a collection of tips to improve one s online communication, based on ideas and feedback that I collected from pestering many experienced and well-respected people for some time. Like every repository of common sense, I think it should be widely promoted but never ever turned into law. It wouldn t be a bad idea to mention it in the Developer s Reference, or to package it as a separate file in the developers-reference package. The reasons I haven t actively been pushing for that to happen are two: there isn t much in the DCG that is specific to Debian, and I don t have the resources to do a proper job maintaining it. It d be great if somebody could take over its maintenance and make it become some proper, widespread, easy-to-quote online reference document, like one of those HOWTOs that all serious people have read at some point in their lives. Raphael: What s the biggest problem of Debian? Enrico: It s sometimes hard to get feedback or help if you work on something unusual. That is partly to be expected, and partly probably due to me not having yet learnt how to get people involved in what I do. Raphael: What motivates you to continue to contribute year after year? Enrico: Debian keeps evolving, so there is always something to learn. And Debian is real, so everything I do is constantly measured against reality. What more intellectual stimulation could one possibly want? Raphael: Is there someone in Debian that you admire for their contributions? Enrico: I don t think I could reasonably list everyone I admire in Debian: pretty much in every corner of the project there is someone, sometimes not very well known, who is putting a lot of Quality in what they do. Someone who decided that X should work well in Debian or that Debian should work well for Y or that Z is something Debian people can rely on and makes sure that it is so. Those are the people who make sure Debian is and will be not just a hobby, but a base upon which I can rely for my personal and working life.

---

Thank you to Enrico for the time spent answering my questions. I hope you enjoyed reading his answers as I did.

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, Twitter and Facebook.

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

report from GHM 2011 Debian and GNU have a lot in common: starting from the fact that strstr() applied to the respective project (full) names does not return NULL, up to the the common objective of building a UNIX-like operating system that grants fundamental software freedoms to its users. That is why I've been very pleased when the organizers of GNU Hackers Meeting 2011 (GHM) invited me to attend and speak about Debian and its relationships with GNU at the event. Slides of my talk are already available, while a video is being encoded (it will probably show up on both GHM homepage and IRILL website). Acknowledging the commonalities of goals on both Debian and GNU sides, we took the chance of this encounter to review how each project feel about relationships with the other (my original inquiries for the Debian community can be found on debian-project) and to talk it over during a discussion session scheduled to happen just after my talk. Yesterday, I've summarized all my notes from GHM 2011 in a report posted to debian-project. Quoting from there: After this experience, it is striking for me how much we have in common with GNU (ideally, culturally, socially, etc.) and at the same time how harsh can our "family battles" become at a times. Let's avoid that the remaining [few] differences get too much in the way [of collaboration], especially when that can be easily avoided. Enjoy!

This is my fifth and final report about dextools for the 2011 Google Summer of Code program. During the summer, I worked with Matt Zimmerman and Stefano Zacchiroli to create a replacement web dashboard for the Debian Derivatives Exchange (DEX). The dashboard displays a list of projects and their respective tasks and then allows users to easily update the status of these tasks. The dashboard also contains two graphs for tracking the progress of projects and providing instant recognition of all contributions to a project. At the start of the summer, I knew that I wanted to to work on improving the DEX infrastructure. I had worked with the team on the ancient-merges project, and while a lot of good work was accomplished, the process for tracking our progress was a bit clunky and difficult to interact with. Anyone who read my initial proposal for the Summer of Code would probably agree that it was quite vague. I really did not have a solid plan for what I wanted to accomplish. This began to change after my initial phone call with my mentor, Matt Zimmerman. We decided that the first thing I would work on would be a basic dashboard. Our plan was to have all of the data stored on the Debian BTS. This would allow Debian Maintainers to benefit from DEX without needing to learn about DEX s tools and workflows. The dashboard would support multiple derivatives and multiple projects for each derivative. Each project would be made up of a list of tasks, where each task is linked to a BTS bug. I prepared a mockup and some initial code based on that plan. The dashboard was able to successfully display a list of BTS bugs and their information. It generated the lists by assuming that bugs would be usertagged with a user of debian-derivatives@lists.debian.org and a tag in the format of dex
. At this point, we started trying to make sure that the dashboard would work for things like the ancient-patches, python2.7, and the upcoming large-merges projects. It did not take long to determine that it would not work for all of these things. The ancient-patches project started with a simple list of patch names. While most of these patches eventually ended up as bugs on the BTS, they did not start this way. The dashboard would need to support specifying a list of task names. This meant that it would also need to store data itself and that not all data could be located on the BTS. This is when we first started to define what a task is. The dashboard tracks tasks. It does not directly track bugs or patches. A task is nothing more than a title and status with an optional assignee, note, and bug. This made it simple to convert a list of patch names or a list of bug numbers to a list of tasks. During the early early stages of the project, the dashboard moved around a lot. We hoped to have it end up on dex.alioth.debian.org, but we were not sure whether Alioth would meet all of our needs. This was right around the time of the Alioth migration. Thanks to some tips, I figured out that I could use a simple cronjob on wagner to pull the git repository for vasks. This would allow the running instance of the dashboard to always be up-to-date. The Alioth admins have also been quite supportive. They have installed several additional packages for me that were necessary to keep the dashboard running. From the start, Matt felt it was important to have some public documentation about the project. This would allow us to point people to something other than my blog posts. I decided to put this information on the wiki. At one point, I also had a copy of the wiki page stored in the git repository. This file was updated via a cronjob, and I then committed and pushed it when I had code changes. I ultimately decided that the best approach would be to maintain the page on the wiki. A basic README file is included in the git repository that simply links to the wiki page. On wagner, I have a cronjob running to pull a copy of the wiki page so that it can be accessed via the web. Since Matt was traveling/moving this Summer, he arranged for Stefano Zacchiroli to fill in for him as my mentor temporarily. It was at this point in the summer that I began working on the first graph script. The goal was to have a script to parse the list of tasks and generate a graph showing the number of open tasks versus time. This would allow us to easily track our progress, estimate when a project will be complete, and detect periods of slowing down. We decided that while we liked the Ubuntu burndown charts, they were a bit more complex than we needed, so we did not reuse their code. A dashboard that can t be modified is not that useful. An early goal of this project was to allow users to update the dashboard via the web. This proved to be a bit more difficult than I initially thought. First, all of the html files that make up the dashboard are generated by a script. This means that if you modify one of the html files directly, all changes will be lost the next time the script runs. When you make a change on a web form and hit submit, you usually expect to see the changes the next time you visit the page. In order to accomplish this, I made the form processing script directly modify the html files. However, at this point, we did not have a way to locally store extended information about tasks, causing the python script to delete all changes made via the web form. This issue was rectified fairly quickly. There is now a changes file that stores all information submitted via the web form. The python script reads this file and applies the changes when it is generating the html files. A second problem concerned the text inputs that were being used in most of the cells on the table. By default, some fields would have text cut-off if the string was too long. Text inputs have a size attribute that is meant to specify the number of visible characters. I attempted to set this attribute in a script to the length of the input s value. Strangely, the inputs ended up with a lot of extra whitespace following the text. This resulted in the table being stretched horizontally. After many hours of research and testing, I was unable to find a solution to this problem. We ultimately decided to simply remove the size attribute and accept that text will be cut-off. My code got some early testing from Allison Randal and other people working on the dex-ubuntu-python2.7 project. They were a huge help in providing feedback and finding bugs in the code. While the dashboard was unable to meet all of their needs (due to being in the early stages of development), I hope that it at least helped to make it easier to track the project s status. Whenever a script is accepting input from a user, it is important to validate it. Although the dashboard uses a select box to limit the choices for the status , it is still trivial to submit an arbitrary status for a task. That is why I added some validation to the form processing script. It will ignore any unknown values, ensuring that all tasks have a valid status. The other fields are a bit more tricky. They were designed to be arbitrary text fields. As a result, almost anything can be entered. There is no way to tell if something is a title or a person. We thought of a few ways we could change this, but most of them involved locking down the dashboard and restricting changes. The old dashboard treated the fields as arbitrary text, so we decided to not include any validation in the new one. One popular feature request was the ability to link directly to a project. Early versions of the dashboard had one main dex.html page that used javascript to pull in the various projects. To get around this, I first trying using the query string to allow users to specify a distribution and project. While this worked, it resulted in long and ugly URLs. It took a while for me to be able to implement a cleaner solution. However, I eventually split each project into its own static HTML file. This meant that people could simply copy the URL from the address bar to link to a particular project. The main reason for doing this was that we felt the typical person would be interested in working on a specific project; most people won t be interested in navigating between the different projects. This change also allowed links that utilized the #graph anchor to function properly. Before, due to the way the page went about loading the project, trying to specify a specific project and #graph in the URL did not work properly. There is a plugin for jquery that allows tables to be sorted by particular columns. For tables that just contain text, this works fine without any issues. However, once I started using select boxes and text inputs, things got a bit messed up. After some research, I finally figured out how to use addParser to instruct the tablesorter plugin in how to sort each column in the table. In some of the earlier versions, I used some zebra stripes to make the table easy to read. Thanks to a suggestion from Paul Wise (pabs), I got rid of this striping and modified the code to color the rows based on the task s status. Complete tasks are green, in progress tasks are yellow, and incomplete tasks are red. This makes it very easy to find tasks that still need work as well as measure the overall status of a project. Sometimes, a large task list can feel very intimidating. That is why I added the ability to hide completed tasks with the check of a box. Matt wanted to take this one step farther; he wanted the ability to also hide tasks with a closed bug. This is why you will find 2 checkboxes at the top of the dashboard that allow you to custimize which tasks are visible. Eventually, I might add support for specifying this in the URL to allow groups to link to a particular view of the dashboard. In order to make it as easy as possible for new contributors to get involved with DEX projects, I wanted to have a way to document what a project is about and how to handle tasks. I decided to use the wiki for this. All of the per-project documentation lives at http://wiki.debian.org/DEX//
. You can even take advantage of wiki markup to format the documentation. The script will parse the HTML files generated by the wiki, do some minor cleanup, and then display the documentation at the top of the page. My original plan was to use the ?action=raw output, but the lack of formatting proved too restrictive. My second plan was to try and use something like BeautifulSoup or a regex to filter non-whitelisted tags out of the wiki-generated html. This failed and proved to be unnecessary. The wiki does a pretty decent job of preventing malicious markup from ending up on the dashboard. There is a second graph that is displayed on the dashboard. This graph shows the number of tasks each person has completed. The graph is sorted so that the tallest bars on the left, and the goal is to provide some immediate recognition of work done by contributors. Since we essentially allow anyone to go ahead and modify the dashboard, we knew it was important to have a method in place for dealing with abuse. Any malicious edits made on the wiki can easily be reverted. This idea of reverting to an earlier revision is what inspired me to use a second local git repository to store the projects/ directory. This directory stores all of the changes made via the web interface. Whenever the form is submitted or the script runs to update the list of tasks, any changes made to the projects/ directory are committed. This means that if a malicious user decides to delete everything on the dashboard, we can quickly and easily revert the changes. The revision history might also be interesting to analyze at a future date. When multiple people are collaborating on a project, an issue tracker can be quite useful. For some reason, we did not set one up until quite late into the project. Despite that, we are still using it to track known bugs and feature requests. The issue tracker will become even more useful once the dashboard starts to be utilized by more people. I spent a fair bit of time working on having the dashboard immediately respond to changes. For example, if you change the status of a task, the row color will instantly update. The form will also be submitted in the background, eliminating the need to hit submit to save the change. I also use ajax in some new dialogs that allow the user to create new projects and/or tasks via the web. While these forms are submitted in the background via ajax, I am unable to have the changes show up on the dashboard immediately. The generation of the task list is a bit slow, so having the script run more often is not really a good idea. The next step for the dashboard is to really open it up for testing. We hope to start up a new DEX project shortly. This will allow us to see which features work and which need fixing. It will also help us find some of the bugs that are probably hiding in the code. Finally, if you are interested in helping out with DEX or dextools, my code is available in a git repository (http://anonscm.debian.org/gitweb/?p=dex/gsoc2011.git) on alioth. There is also the issue tracker (https://alioth.debian.org/tracker/index.php?group_id=100600&atid=413120) where you can report bugs and request new features. Finally, you can join the debian-derivatives mailing list, join #debian-derivatives on OFTC, or contact me directly via email or on IRC (nhandler). I have really enjoyed working on dextools this summer. I would like to thank Matt Zimmerman, Stefano Zacchiroli, and everyone else who helped with the project. I look forward to working with all of you more in the future.

When I think about Margarita, I always remember her as a friendly and welcoming person. Like most of the Debian Women members by the way. But she likes to spread some love and organized a Debian Appreciation Day for example. I think I met her in real life for the first time at Debconf 6 in Oaxtepec (Mexico). She deeply cares about Debian in general. She has proven it multiple times with her DPL candidacy and by giving talks like Making Debian rule again. One last thing, Debconf11 is just over and you will see that Debconf4 has had a big influence on Marga. My advice is simple: next time there s a Debconf on your continent, make sure to take a few days off and come to meet us! It really gives another picture of the Debian community. Now let s proceed with the interview. Raphael: Who are you? Margarita: I m Margarita Manterola, a Software Developer from Argentina. I work developing software in Python in a Debian-friendly company during the day, and teach programming at a local university during the evenings. I m married to Maximiliano Curia who is also a Debian Developer, most of our Free Software work has been done together. I only maintain a handful of packages in Debian, I m more interested in fixing bugs than in packaging new software. I ve also been a part of the organizing team of many of the previous Debian Conferences. One of the biggest commitments and the biggest success of my participation in Debian was being part of the organizing team of DebConf8, in Argentina. Raphael: How did you start contributing to Debian? Margarita: I started using Debian around 2000. Soon after we had learned the grips of general GNU/Linux usage, Maxy and I started giving an introductory course at our local university, and became quite involved with the local LUG. At some point in 2002/2003 I became a Debian Bug Reporter : most of my friends would report bugs to me, and I would then write them in the proper form to the BTS. I would also be very attentive about reporting any bugs that I might encounter myself trying to create good bug reports. The turning point in my participation in Debian was DebConf4 in Porto Alegre, Brazil. Being so close to Argentina meant that we felt specially invited to be there, and Maxy and I decided to go to DebConf for our honeymoon. We didn t really know much about DebConf dynamics, but we were really eager to learn more about Debian and become more involved. What happened was that meeting with DDs from all over the world transformed our lives, we became part of the Debian family and wanted to be more and more involved. Soon after that we both started maintaining packages and not long after that, applied to become Developers. The Debian Women project also meant a lot to me. I felt encouraged all along the way, encouraged to learn, to ask questions and to lose the fear of making mistakes. I became a Debian Developer on November 2005. Since then, Debian has always been one of the most important things I do in my life. Raphael There was a Debian Women BoF during debconf. What are the plans for Debian Women in the upcoming months? Margarita: I was not there in person, but thanks to the awesome work of the video team, and of Christian Perrier s typing efforts when something failed, I was able to experience much of what was discussed. One of the many points that came up during the BOF is that many people Want to help but don t know where to start or how to go about it. It s a challenge for the Debian Women project to find a way to allow these people to become involved in Debian through Mini projects or something like that. Another of the subjects that was brought up was the Debian Women mentoring project, which has been going on for quite a while now, but lacks enough publicity. So, we need to reach more people about it, and maybe also improve it with some templates, similar to the New Maintainer templates, so that mentees that don t know where to start have some sort of general path to follow. Raphael: You created very useful diagrams documenting how package maintainer scripts are invoked by dpkg. How did you do it and was that a useful experience? Margarita: I did those diagrams to be able to answer one of the questions in the NM templates, regarding the order of the maintainer script execution. Answering the question in text was basically copying and pasting the part of the Debian Policy that explained it, which wasn t really too clear for me, so I decided to go and make a diagram of it, so that I could really understand it. I did it by the best of all debugging techniques: adding prints to each of the maintainer scripts, and testing them in all the different orders that I could think of. It was a useful experience at the time, because I learned a lot of how maintainers scripts work. I didn t expect the diagrams to become so famous, though, I only did them to answer one NM question, that I assumed most other people had already answered before Raphael: You participated in a DPL election. This is a big commitment to make. What were your motivations? Margarita: As I said, I was part of the organizing team of DebConf8, in Argentina. Which was quite a success, a lot of people enjoyed it and praised the good work that had been done by the local team. During said DebConf8, I had a dream (it was almost a nightmare, actually): I woke up and just like that, I was the DPL. I spoke to some people about this dream and to my complete surprise many said that I should actually do it. After giving that possibility a year and a half of thoughts, during the 2010 campaign I was talked into participating myself as a candidate, and it was a very interesting experience. However, I m very glad that Zack got elected and not me, I think he makes a much better DPL that I would have made. Raphael: What s the biggest problem of Debian? Margarita: I think the main problem that we have is our communication, both inside the project and outside the project. Most of us are very technical people, our skills lay in the technical part of Debian (preparing packages, fixing bugs, writing software, administering systems) not in the social part. And thus, we lack a general empathy that is quite needed when interacting with people from all over the world. Raphael: Do you have wishes for Debian Wheezy? Margarita: Not particularly. I do want it to be a great release with good quality, stable software. I would also like to keep making Debian more and more universal with each release, making it more user friendly, more accessible, and more robust than any other previous release. Raphael: Is there someone in Debian that you admire for their contributions? Margarita: I admire a lot of people in Debian. There s a lot of people that contribute a lot of time to Debian, amounts of time that I can t begin to understand how they can afford. I admire Stefano Zacchiroli, our current project leader. And Steve McIntyre, the project leader before him. Also Bdale Garbee, who s also been a DPL in the past. Making this list I realize that Debian has been blessed by quite a number of great leaders in the past. I admire Holger Levsen, for his contributions to the DebConf video team, that have made it possible year after year for the whole project to participate in DebConf remotely. I admire Steve Langasek and Andreas Barth (etch is still my favourite release). I admire Christian Perrier for his work on internationalization. I admire Joerg Jaspert for the incredible amounts of time that he puts into Debian. And actually, I could go on admiring people all night long. I admire so many people that this interview could become a very boring list of names. I guess it s better to leave it at saying that Debian is lucky to have quite a lot of excellent hackers around.

---

Thank you to Marga for the time spent answering my questions. I hope you enjoyed reading her answers as I did. 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, Twitter and Facebook.

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

Due to the midterm evaluation, this report will cover a span of 4 weeks. As a result, it will be quite a bit longer than my previous reports. One of the first things I did after my last report was create a FAQ for the project. At first, the FAQ was a plain text file living only in the git repository. Then, it moved to being maintained on the Debian wiki with a cronjob pulling it into my local repository for me to commit and push. Finally, the cronjob moved to wagner. The FAQ is not actually committed to the git repository, but it is available in the dextools instance running on wagner or on the wiki. There is also now a basic README file that is part of the git repository that simply points people to the FAQ on the wiki (so people who branch the repository can easily find the documentation). For those of you who have been reading my other reports and/or testing the dashboard, you have probably noticed the problems I was having getting the text boxes sized properly. After spending countless hours researching and testing different solutions, we finally decided to give up on this for the time being. Therefore, all of the size attributes have been removed from the text inputs, and the background color has been reset to its default value. This means that we will no longer experience the issue of very wide text boxes and a horizontally stretched table. However, it also means that long strings will get cut-off when displayed in a text input. Since my initial mockup design at the start of the summer, I have had the rows of the table zebra-striped. Based on some feedback from Paul Wise (pabs), I changed this so that the row colors are based on the status of the task. Open tasks are red, closed tasks are green, and in progress tasks are yellow. This makes it much easier to quickly see the progress of the project and find tasks you are interested in. My original dashboard consisted of one main dex.html file. This file used some javascript to pull in each project s task list. We felt that a much more common use case would involve a user only interested in one particular project. As a result, they would not be likely to use the select boxes to change projects. This ultimately led to me creating standalone dex.html dashboards for each project. These per-project dashboards were identical to the original dex.html, except they did not include the select boxes at the top for changing projects. Eventually, I decided to completely get rid of the original dex.html dashboard. That file now consists of a simple list of links to all of the projects sorted by distribution. Another advantage of this change is that it is much easier to link to a specific project. For example, you might now link to /projects/dex-ubuntu-ancient-patches/dex.html (you can get the URL by simply copying it from the address bar). Another advantage is that you can now link directly to a specific project s graphs (just append #graph). Another feature that I am still working on is per-project documentation. From the start, we wanted to make it easy for new contributors to get involved in DEX. One way we can do this is by having clear documentation about what the project is and how to deal with tasks. I decided that the easiest approach would be to have this documentation live on the wiki. This allows users to use the familiar wiki markup language to format their text, and it gives us all of the other benefits a wiki provides. Documentation will live at /DEX/<distribution>/ <project>. The dashboard will then take care of pulling in this documentation and displaying it at the top of the proper page. For a while, I was thinking that it would be necessary to filter the HTML produced by the wiki to prevent malicious code from ending up on the dashboard. However, after playing around for a bit, I think that it should be pretty safe to just use the HTML as-is (if someone spams the wiki, we can always revert the change). I am currently finishing up some of the code to handle this, and it should be live sometime this week (a partially working version is live on wagner). There are also two new checkboxes at the top of each dashboard. These allow users to add completed tasks and/or tasks with completed bugs. This is useful for projects that are close to being complete, as it allows users to quickly view the few remaining tasks. This feature was requested by several people, and I am glad to finally be able to implement it for them. There is also a second graph on each page. This graph is a bar graph that shows the number of tasks each person has completed. It gets the people from the assignee column for the project, and it only counts tasks with a status of Complete . The graph is updated whenever the getbugs.py script runs to update the task listing (currently every 10 minutes). The bars are sorted from tallest to shortest. The idea behind this graph is to recognize the people working on a project. The form processing script has not worked on wagner. This was mainly due to a permission issue. Thanks to a hint from Rapha l Hertzog, I was able to use setfacl to fix this. The form can now be submitted, and it should successfully save all changes made via the web form. This involved some updates to support the per-project dex.html files. The form processing script will also ignore any status that is not complete , in progress , or incomplete , which prevents people from messing up the dashboard by submitting invalid information. Finally, the script will now try to use the HTTP_REFERER header to send the user back to the correct page. If this header is not set, the user will be sent back to the main dex.html index page. Sorting the table has been partially broken since I started including text inputs. I finally got this issue resolved, and I should now be able to sort by text inputs, select boxes, or anything else I might end up including in the table. You can test this by clicking on any header in the table. I will probably add a tiny image to make it more clear which header is being used to sort the table. By default, it is sorted based on the status and then the task name. The status column now has a select box for setting the status. Since the row coloring is done via javascript, the minute you change the status in the select box, the row color will change to reflect the new status. Keep in mind, for the time being, any change you make via the web form will be lost if you do not hit the Submit button at the top of the form. That covers most of the dashboard changes that have taken place since my last report. However, there were also some other changes that are worth noting. Matt Zimmerman, my original mentor, settled down from his traveling and resumed serving as my mentor for the project. I would like to thank Stefano Zacchiroli for all of his help this summer. I look forward to working with him more in the future. I have also started using the issue tracker feature on alioth for dextools. Right now, it is mainly being used to help me keep track of bugs and features that I need to deal with. I am hoping that as dextools starts to be used by more people that they will also help report issues on the tracker. This issue tracker is a good source of information for people interested in knowing what I will be working on in the future. I will briefly talk about some of the more important features that I will be working on. The first issue is one that I have already touched upon in this report. I want to sort out the per-project documentation. This is rather important, as it will most likely be utilized by all projects using the dashboard. It is also essential if we are to get new contributors involved in DEX projects. Second, I want to setup some method for backing up the projects/ directory on wagner. This directory is not maintained in the git repository, and it contains all of the information submitted via the web form and generated by the scripts. My current plan is to have this directory maintained in its own VCS. Every time getbugs.py runs or the form is submitted, a new commit will be made. This will allow us to easily revert any changes (spam) made to the dashboard. Since we do not foresee the dashboard being the target of much abuse, any user will be able to modify data via the web form. I also want to add the ability for users to create new projects and task via the web. I envision this as a separate form where they enter the distribution name, project name, a list of BTS bug numbers, and a list of any additional tasks. The script will then take care of applying the necessary usertag to the bugs and/or creating a tasks file in the projects directory for the non-bts tasks. Doing this will make starting a new project trivial, and will eliminate the need for VCS access to create projects that do not utilize BTS bugs. Finally, I want to eliminate the need for the user to hit the Submit button to save their changes. Any change the user makes should be submitted and saved instantly using AJAX. This will also help eliminate some confusion that was caused by the row color instantly changing when the status is changed. Some users thought that the color change meant that the change was saved when it really was not. Matt asked me the other day what features I think need to get added before the dashboard is really ready for public use. While the features and issues I mentioned above will help make the dashboard easier to use, the dashboard is still perfectly usable without them. There are only a few more weeks left in the Google Summer of Code 2011. By that time, all of these features and bugs should be sorted out, and we should be able to properly announce the dashboard and make it available for use on all DEX projects. That does not mean that the dashboard will be done . Instead, it will probably result in many new bugs and feature requests being submitted. However, at that point, I will make a very strong effort to keep the dashboard stable and to prevent data loss. I am looking forward to the finally finishing up this project and seeing it used by the DEX team. As always, if you are interested in helping out with DEX or dextools, my code is available in a git repository on alioth. There is also the new issue tracker where you can report bugs and request new features. Finally, you can join the debian-derivatives mailing list, join #debian-derivatives on OFTC, or contact me directly via email or on IRC (nhandler).</project></distribution>

During Debconf11, I've tried a couple of times to eat Cevapi, but for one reason or another I didn't manage to. On my way from Banja Luka to Split, I've stopped my motorbike in the proverbial middle of nowhere for lunch (the fact it was raining cats & dogs helped in not having much of a choice). As a consequence, the waiter I ended up facing didn't speak a single word of any language I know. The only three words of Bosnian I managed to say were luckily the right ones: evapi, pivo, and voda. The only missing ingredient for a perfect DebConf in the Balkans evapi has hence been acquired before leaving the country. Everything else was already there: intense hacking, truckload of emotions, tiny teeny bit of stress, feeling of family, and physical exhaustion. No sign of DebConf flu (yet). In case you missed a specific event or the conference all together, hail the Videoteam for having already made available the videos on video.d.n. They can provide useful entertaining for the forthcoming weeks. For what is worth, I plan to spend the next two weeks elsewhere in the Balkans with very little Internet (as in: none at all). Talk to you later.

why proprietary relicensing is unacceptable for a Free Software enthusiast The past few months have witnessed a large debate about copyright assignment, which seems to has neared its peak around the time Project Harmony has released version 1.0 of its agreement templates. (Note: I use the expression "copyright assignment" in this post, but I'd happily include into it both actual Copyright Assignment Agreements CCAs and Contributor License Agreements CLAs, as both could be used to permit various forms of proprietary relicensing.) Mark Shuttleworth has been one of the most prominent voices campaigning in favor of copyright assignments (to for-profit companies). A couple of interesting blog posts of his where this is evident are "On balancing economic power in the FLOSS ecosystem" and "The responsibilities of ownership". Voices against the opportunity of increasing the popularity of copyright assignments are aplenty and it is pointless to repeat good arguments which I find fully convincing. If you are interested in the subject, here are a few good reads I recommend:

• "Some thougts on copyright assignment", seminal essay (circa end of 2009) by Michael Meeks that provides a good coverage of copyright assignment basics and effects on the surrounding ecosystem
• Richard Fontana's "The trouble with Harmony"; in particular, I recommend taking a close look at "The illusion of constraint" part

What I would like to add to the debate is the point of view of a Free Software enthusiast, not unlike yours truly. I contribute to Free Software not because it is superior to proprietary software in either its software products or in its development methodology. (It actually is superior in many cases, but that's just not my primary motivation.) I do contribute to Free Software to build a world in which users are in complete control of the software they run. Let's assume we have a broken toaster at home. We are all free to (1) open it up and try to repair it by ourselves. If we don't have the needed knowledge, we are free to (2) hand it over to a person that we trust and who does have the needed knowledge to repair it. That failing, we can (3) ask the toaster producer to repair it for us. Many people like me simply don't accept to live in a world where, once all the toasters will be software-driven, the only repair option will be (3), just because the toaster software is proprietary. (Given various kind of [broken] metaphors have been used to explain copyright assignments, it seemed sensible to propose my broken toaster metaphor in exchange.) When I contribute to some Free Software project, I not only care about being able myself to get a Free Software licensed copy of the whole product (i.e. the original software product + my own contribution). I care that all recipients of the product, present and future, will be able to get that contribution with enough freedoms attached to put them in control of the software that includes it. This desire can be fulfilled with a varying degree of success, depending on the license of the code base I contribute to. For instance, I find more pleasant to contribute to a copyleft licensed code base than to a weak-/non-copyleft licensed one, and more pleasant to contribute to an AGPL-ed web app than to a copyleft web app. It also means that, given the option, I will not allow the code base maintainer to re-license my contribution under terms that allow distributing it without suitable freedoms attached. Different contributors will be ready to accept different re-licensing promises, but the mere fact we are debating all this and that companies like Canonical feel the need of campaigning for copyright assignments is evidence that many contributors like me exists and actually have a problem with allowing downstream relicensing of their contributions. What is feared the most is of course proprietary relicensing. According to my moral horizon this is the case not because the company might end up gaining money out of my code: I wouldn't have a problem with that. The reason is rather that the company will be able to distribute my own code in a way that grants less freedoms to users than those that were implicitly "agreed upon" when the contribution has been written. In that respect, I can't help thinking at harmony agreements as a large scale smoke screen experiment meant to convince volunteers that copyright assignments are something Free Software needs. By exploiting the creative-commons-like "it's easy, just choose one" scheme, Harmony takes the chance of offering misleading options such as the one labeled "any OSI approved license". Via that option, which is seemingly fine, the copyright recipient will be allowed to relicense the contribution under some non-copyleft license (e.g. BSD) and from there do essentially what they want. All in all, companies campaigning for copyright assignments seem to have failed to understand two main points. The first one is that contributors motivated by Free Software ideals want the code to remain free not only for themselves, but for all recipients of the code. I'm not claiming that all contributors to FOSS projects belong to this category, but the fact that there is a considerable amount of such people is undeniable. Hoping that they will be fooled by tricks like the "any OSI approved license" agreement is foolish. The second is that while volunteer Free Software communities do respect companies that provide huge amounts of code contributions, they also expect companies to figure out by themselves which business models make their businesses sustainable. Telling volunteers that current business models are not sustainable without proprietary relicensing is worthless. Volunteers just don't care. They want software freedom guarantees and are not willing to renounce to them in exchange of the wealth of companies, not even under the (implicit) threat that otherwise those companies will be forced to reduce the amount of their code contributions.

---

Update: explain in the initial note why my reasoning here encompasses both CCAs and CLAs. Thanks Tollef for noticing that it wasn't clear.

average sprint speed: 1 sprint/month I've proposed a DebConf11 BoF on Debian sprints and, more generally, on how we have been using Debian money in the past 1.3 years. As part of the BoF preparation, I've taken the time to review the last 16 months of sprints and check how the Debian Sprint Program which we've recently streamlined and "marketed" quite a bit is going. In particular, I've finally done the homework of preparing the big table of sprints and their costs, in order to evaluate how sustainable the sprint program is. Without further ado, here is the table:

Debian sprints held from April 2010 to June 2011

No	Sprint	When (month)	Where	Attendees	Debian cost (EUR)
1	groupware (report)	04/2010	de	4	240
2	FAI (report)	06/2010	de	7	570
	(DebConf10)	08/2010	us
3	ftpmaster (report)	09/2010	de	3	350
4	DSA (report)	09/2010	de	3	400
5	release team (report)	10/2010	fr	6	0
6	kernel team (report)	10/2010	fr	3	120
7	www team	12/2010	at	5	1430
8	debian med	01/2011	de	25	460
9	security team	01/2011	de	7	1000
10	emdebian	02/2011	uk	17	0
11	ftpmaster	03/2011	de	5	2000
12	groupware	04/2011	de	6	300
13	alioth	05/2011	uk	4	500
14	debian edu	06/2011	de	9	760
15	release team	06/2011	be	5	1640
	(DebConf11)	07/2010	ba
Total	15 sprints	16 months			9770

To better understand the table, several comments are in order:

• numbers are approximate in various ways. In particular, 2010 costs predate a protocol I've agreed upon with the Debian auditors to do proper accounting, hence it is possible that some costs are slightly overestimated
• costs are Debian's costs and do not include reimbursements for non-Debian people that might have attended the sprint. This also explains why some sprints have been at 0 cost: they have been entirely sponsored by other entities interested in supporting Debian, such as companies or institutions.
• where needed, costs have been normalized to Euro
• we have streamlined the sprint process around October 2010 (you can find the underlying rationales in an old RFC). Sprints happened before that data had a different way of being announced and of reporting back to the project.
• the above data are not detailed enough to properly estimate per-person costs, as we lack a breakdown of Debian vs non-Debian attendees
• no costs for DebConf-s are included, as they have their own budgets which aims to be amortized 0 cost in the long run

Please note that the purpose of the table is not to be precise and transparent about Debian finances and how we use them. That is a (very!) worthwhile goal and I do think Debian should do much better in informing its community about how donated money are used to further Debian goals. But that is a broader topic on which the auditors are working; it is not up to me to discuss it here. If you are interested in that topic though, you might want to follow tbm's BoF at DebConf11. The purpose of the table is rather to find out some general figures about Debian sprints held in the recent past:

• we have had a total of 15 sprints in 16 months (about 1 sprint/month)
• we have spent about 10'000 EUR for sprints, for an average per-sprint cost of about 650 EUR
• all sprints have been held in Europe
  (given DD geographical distribution, I find quite surprising that no group of US-based Debian hackers have asked for sprint sponsoring)
• about half of the sprints have been held in Germany
  (probably thanks to DD-density there and also to the welcoming attitude of friendly venues such as the Linux Hotel)
• the variance of per-person costs is high: there are very cheap sprints (e.g. when people travel within Europe by train and stay at friends') and quite expensive sprints (e.g. when one or more of the participant needs to be flown oversea which has happened only once, up to now)

I'm personally quite happy about those figures. Enabling volunteer developers to meet and hack together in person is possibly the most valuable way of using donated money. Having 1 sprint/month is not bad, but in a project the size of Debian is quite possibly a minimum. Doing more than that is highly desirable. It is also financially sustainable, especially if we will be able to show by actually having more sprints and being transparent about them that we can put into good use donated money. Another, more subtle, aspect of sustainability is that related to sprint management. Processing sprint requests and ensuring that transparency guidelines are actually followed by the organizers is still quite some work. I've been mostly doing that myself up to now, which is all fine and well, but does not necessarily scale. Other organizations (such as KDE e.V.) have realized that to the point of having hired people specifically to manage sprints in an otherwise volunteer community. In Debian we are quite keen of maintaining the project running on a volunteer basis. At the same time I feel we should have more room for scalability in the number of sprints we could run. So if you are looking for a management task to help Debian with, think about becoming, err, "sprint master", and contact me. If otherwise you want to focus on Debian hacking, what are you waiting for? Check the guidelines and propose your sprint! To know more about sprints, Debian money, and how you could help with all that, be sure not to miss the Sprint and money BoF.

At last DebConf, with the help of Gregor, I've tried to summarize some BoF organization best practices in a sort of HOWTO. As promised, although with 1 year of delay, we have just moved the DebConf BoF HOWTO to a more stable place on the DebConf wiki. In doing so, we have also integrated some of the feedback received last year. If you've proposed a BoF at DebConf11, please take a minute to have a look at it and let us know your comments. As usual, your feedback and contributions to improve the text are more than welcome!

... or TDDD and DEP8 context As a nice byproduct of the huge "rolling" discussion we had back in April/May, various people have brainstormed about applying Test-Driven Development (TDD) techniques to Debian development. Here is a brief summary of some opinions on the matter:

• a seminal conversation on identi.ca
• a couple of blog posts by Lars, discussing the general problem of how to use TDD in distribution development and to a lesser extent its instantiation to Debian
• a separate post by Daniel stressing the specific TDD advantage of increasing the confidence of maintainers in making far reaching changes

... and hey, they've also coined the cool TDDD acronym, which I hereby took the freedom to re-target to Test-Driven Development in Debian. Having a cool acronym, we are already half-way to actually having the process up and running *g*. more testing I believe Debian needs more testing and I've been advocating for that since quite a while e.g. at DebConf10, as one of the main goals we should pursue in the near future. Of course advocating alone is not enough in Debian to make things happen and that is probably why this goal has been (thus far) less successful that others we have put forward, such as welcoming non-packaging contributors as Debian Project members. There are important reasons for increasing testing in Debian. quality assurance Quality Assurance has always been, and still is, one of the distinctive traits of Debian. I often say that Debian has a widespread culture of technical excellence and that is visible in several places: the Debian Policy process, lintian, piuparts, periodic full archive rebuilds, the EDOS/Mancoosi QA tools, the cultural fact that maintainers tend to know a lot about the software they're packaging rather than only about packaging, the we release when it's ready mantra, etc. But caring about quality is not a boolean, it's rather something that should be continuously cherished, refining quality requirements over time. By simply maintaining the status quo in its QA tools and processes, Debian won't remain for long a distribution who could claim to care about package quality. Others will catch up and are in fact already doing that. In particular, we surely have room for improvements in our quality tools and processes for:

• Build time package testing. Several packages run their build-time test suites during package build. This aspect is somewhat supported by the Debian policy; we also do a best effort attempt to run build-time test suites via debhelper (starting from version 7). At the same time we could probably campaign more to encourage maintainers to look for build-time test suites which do not follow common Makefile target naming or, fwiw, which don't rely on make at all. TodoList.add("investigate and possibly file bug report against policy to encourage maintainers to run build-time test suites")
TodoList.add("investigate and possibly file bug report against lintian to spot the presence of [non-invoked] build-time test suites")
• Runtime package testing (AKA "as-installed package testing"). Some kinds of test-suites are difficult to run at build-time (e.g. complex applications that don't offer easy way to re-configure on the fly their filesystem paths) and some others are plainly impossible to run without having the packages to be tested properly setup (e.g. running services that are accessible only through the network) or an isolated, throw-away testbed (e.g. bootloaders, kernels, etc.). TTBOMK this kind of testing is not currently in use neither in Debian nor, indirectly, in any of its derivatives. autopkgtest (AKA DEP8) is a step in this direction; I will get back to it later on in this post.
• Integration testing. When applied in the context of distributions, integration testing is about testing package combinations, task (as in tasksel) combinations, basic system functionalities, automated installations, etc. This is the aspect that Lars has discussed the most (and in which he seems to be interested the most) so I don't feel like adding much. Still, it's interesting to note that on this front Debian has an important potential to exploit. The large base of its developers and the fact that the average Debian user is technical savvy mean that we can potentially collect a lot of test cases. It's "just" (with well-deserved double quotes) a matter of deciding a standard interface for test case submissions and developing a most likely virtualized test runner. At that point a continuous integration service that periodically run and publishes results can be setup independently from the rest of the Debian infrastructure and offered to interested eyes, such as Release Team's. Any taker?
• Automated code analysis and in particular automated bug finding is something which is becoming more and more common and finally, after decades of research viable. Successful proprietary tools and businesses are aplenty (a nice and very fun read on the subject is the story of Coverity), as well as FOSS solutions. For instance, the Linux kernel is routinely using Coccinelle to automatically find bugs and even produce the corresponding patches. Add to the above the fact that Debian is one of the largest software collection in existence (and quite probably the largest collection of Free software in existence) and is upstream of the packaging of that software for the most part. That turns Debian into a very peculiar platform for large scale automated code analyses. Not that we can aim at fixing all the bugs we are going to find, or even hope to tame all the false positives we are going to find. But we can offer an important service to the whole ecosystem of Free software and use it to pinpoint important class of bugs from a distribution point of view, such as nasty security bugs (as long as they can be automatically found ). DACA is a very good step in the right direction, even though it is still in its infancy.

reducing inertia Inertia is a recurring topic among Debian lovers (and haters). It is often argued how difficult it is to make changes in Debian, both small and large, due to several (alleged) hindrances such as the size of the archive, the number of ports, the number of maintainers that should agree before proceeding with a cross-package change, etc. It's undeniable that the more code/ports/diversity you have, the more difficult is to apply "global" changes. But at least for what concerns the archive size, I believe that for the most part it's just FUD: simply debunking the self-inflicted culture about how "dangerous" doing NMUs is might go and has already gone, imho a long way to fight inertia. Adding per-package and integration tests will make us go another long way in reducing inertia when it comes to performing archive-wide changes. Indeed if a package you are not entirely familiar with has extensive test suites, and if they still pass after your changes, you can be more confident in your changes. The barrier to contribution, possibly via NMU, gets reduced as a result. And if your change will turn out to be bad but still not spot by the test suites, then you can NMU (or otherwise contribute) again to extend the test suite and make the life easier for future contributors to that package. It smells a lot like an useful virtuous cycle to me. autopkgtest / DEP8 how you can help Of all the above, the topic that intrigues me the most is as-installed package testing. Work on that front has been started a few years ago by Ian Jackson when he was working for Canonical. The status quo is embodied by the autopkgtest package. At present, the package contains of various tools and the following two specs:

1. README.package-tests provides a standard format to declare per-package tests using the new debian/tests/control file. Tests come as executable files which will be run by the adt-run tool in a testbed where the package(s) to be tested is already installed. This part of the specs has been reified as DEP8 which I'm (supposedly) co-driving with Iustin Pop and Ian (for well-deserved credits).
2. README.virtualisation-sever describes the interface among the test runner and the testbed. A nice separation is provided among the runner and the testbed, enabling different testbed environments with a varying degree of isolation: you can have a "null" testbed which runs tests on your real machines (needless to say, this is highly discouraged, but is provided by the adt-virt-null tool), a chroot testbed (adt-chroot), or a XEN/LVM based testbed (adt-virt-xenlvm).

The specs allow for several runtime testing scenarios and look quite flexible. The tools on the other hand suffer a bit of bitrot, which is unsurprisingly given they haven't been used much for several years. At the very minimum the following Python development tasks are in need of some love:

• The usage of python-apt needs to be ported to recent API, as several used methods and attributes are now gone.
• Porting from dchroot to schroot is needed for the adt-virt-chroot backend.
• A kvm backend for the test runner would be nice.

If you are both interested in TDDD and grok Python, the above and many others tasks might whet your appetite. If this is the case don't hesitate to contact me, I'll be happy to provide some guidance.

---

Note: this post is the basis for the TDDD BoF that I will co-host with Tom Marble at DebConf11. If you plan to come, we will appreciate your thoughts on this matter as well as your help in getting the autopkgtest toolchain up and running again.

Martin Michlmayr is a Debian developer since 2000 and I share quite a few things with him, starting with his age and involvement in the quality assurance team. He managed to be elected Debian Project Leader in 2003 and 2004. He s no longer as active as he used to be but his input is always very valuable and he continues to do very interesting things in particular concerning the support of NAS devices. Read on for the details. Raphael: Who are you? Martin: I m Martin Michlmayr. I m 32, originally from Austria, and currently living in the UK. I ve contributed to various free software projects over the years but Debian is without doubt the one I m most passionate about. I joined Debian in 2000 when I was a student. I worked on Debian more or less full time for a few years while I was pretending to study. Later I started a PhD to do research about quality and management aspects of volunteer free software projects. I investigated the release process in several free software projects, in particular looking at time-based releases. After finishing my PhD in 2007, I joined Hewlett-Packard. I m part of HP s Open Source Program Office and work on various free software and open source activities, both internally and within the community. Raphael: How did you start contributing to Debian? Martin: I first used Debian in the days of 0.93R6, some time around the end of 1995. The 0.93R6 release was still based on a.out but I needed an ELF-based system for some application, so I moved to Slackware. I then quickly moved to Red Hat Linux where I stayed for several years. I rediscovered Debian in 2000 and quickly decided to join the project. I cannot recall how I rediscovered Debian but when I did, it was clear to me that Debian was the ideal project for me: I could identify with its philosophy, I liked the volunteer nature of the project, and I found the size and diversity of Debian interesting since a large project offers a lot of different challenges and opportunities. I remember how many new things there were to learn and back then the documentation and other resources for new contributors were nowhere as good as they are today. My application manager, Julian Gilbey, was a great help he was incredibly friendly and passionate about Debian. I also remember meeting up with Peter Palfrader (weasel) for key signing when we were both in the New Maintainer queue. I was incredibly lucky with my New Maintainer process and soon became an official Debian Developer. Because there was a shortage of application managers, my first major contribution in Debian was to become an application manager myself and help other people join the project. Debian is a large project with a long history and a rich culture, so new contributors should expect that it will take some time to become familiar with everything. Fortunately, there are many resources, such as documentation and the debian-mentors list, for new contributors. Another great way to become familiar with the way things are done in Debian is to subscribe to various Debian mailing lists and ideally to read some mailing list archives. It s also a great idea to attend the Debian Conference or other conferences since meeting people in real life is a great way to integrate. I remember attending Debian Conference 1 in Bordeaux where I gave my first public talk. Finally, new contributors should find an area where they can make a unique contribution. Most people in Debian maintain packages but there are so many other ways to contribute. For example, most of my contributions were not technical but were about coordination and other organizational activities. Raphael: What s your biggest achievement within Debian? Martin: I m particularly proud of a number of achievements:

• New Maintainer: I helped a lot of people join Debian. It s great to help someone join the project and then see how they contribute. Of course, some people join Debian and then quickly become inactive or retire you never know in advance how it will work out. But I had the pleasure to help some truly outstanding contributors to join Debian.
• Quality Assurance: I helped improve QA processes within Debian. In particular, I realized a few years ago that a lot of packages had maintainers who were inactive and that nobody did anything about it. I started to write to those maintainers to see what could be done. It s hard because you don t know the circumstance of someone they may be inactive because of an illness or for other good reasons so you have to be friendly, but yet persistent. Fortunately, most maintainers I contacted were truly inactive and so they couldn t complain when I took their packages away.
• DPL: I acted as the Debian Project Leader for two years. I m particularly proud of this because Debian is a great project and it was an honour to represent it. I performed important organizational and coordination tasks. I also traveled to a lot of conferences and had the pleasure to meet many Debian Developers as well as users of Debian. It s very motivating to meet users and to hear how they use Debian and how we can further improve it.
• Debian on NAS: Debian is without the doubt the Linux distro with the best support for NAS (Network Attached Storage) devices. I was always impressed by what the OpenWRT folks have done to support wireless routers and wanted to do something similar for Debian. Unfortunately, wireless routers just don t have enough storage for a full distro. But then NAS devices came along and they obviously have enough space since they are meant for storage.

Raphael: Speaking about NAS devices: what exactly are you doing on this topic and how can people help? Martin: There are plenty of instructions on the Internet to install Linux distributions on NAS or various embedded devices by connecting a serial console and then typing in hundreds of commands. What I found is that such instructions significantly limit the user base because they are way too complicated for most users. There are just too many steps that can go wrong. So instead, in Debian, we provide a solution that just works: usually, you download a firmware image for your NAS device from Debian and when you upgrade you get the Debian installer. You connect to the installer via SSH and perform a normal installation. The installer knows about the device and will prepare everything for you automatically for example, it knows if the device has requirements for the partition layout and it will install the kernel where the device expects to find it; unfortunately, NAS devices are not like PCs, so the requirements are different for almost every device and therefore you need special code to support a new device. Finally, there are detailed installation guides and we provide help on our mailing lists. There are a number of technical areas for improvement. The installation could be made even easier, and it would be nice to support new platforms and devices. A bigger problem is that while we ve implemented a great solution for NAS devices, we haven t really extended this work to support other classes of devices. For example, tablets and mobile phones are getting incredibly popular and we don t have a compelling solution for such devices, mostly because of the lack of an appropriate GUI. Raphael: What are your plans for Debian Wheezy? Martin: I ve recently been asked by Stefano Zacchiroli, our current Debian Project Leader, to coordinate the care-taking of Debian finances. Debian, as a volunteer project, relies on donations and in-kind gifts (e.g. hardware) to maintain its infrastructure and to support various development efforts, such as funding sprints and other developer gatherings. Debian s money and other assets are held by affiliate organizations around the world. My responsibility will be to keep track of money and other assets (e.g. hardware and trademarks), work with the DPL to establish procedures related to the use of Debian s assets, and make sure that the procedures are followed. Finally, we want to publish public statements so our donors know how we use their donations to further improve Debian. I just started working on this and this will be my main activity in Debian in the coming months. Raphael: Speaking of money, I plan to run a fundraising to get the Debian book I wrote with Roland Mas translated (cf. http://debian-handbook.info). Is this something Debian should support? Martin: First of all, I should make it clear that I don t decide how Debian spends its money. This is up to the DPL to decide together with the project at a whole. I ll just make sure that procedures are followed and expenses tracked and reported properly. Having said that, in my opinion, it s unlikely that Debian as a project will fund this effort. It would be inconsistent with the position of the project not to fund work directly (only some related expenses, such as travel costs to allow Debian teams to organize face-to-face meetings). Whether Debian should support the fundraising effort by helping to promote it is another question and that s probably not as clear cut. It looks like a worthwhile effort, but on the other hand it would be unfair for authors of other Debian books for Debian to put its weight behind one and there are many other efforts that are worth promoting if you promote one, where do you stop? So while it sounds worthwhile, it s probably better for Debian to stay out of it. But somehow related to this, I sometimes worry about the fact that there are so few paid opportunities around Debian. If you contribute to the Linux kernel for a while, you have an excellent chance to get hired by someone and to work on the kernel full time. The kernel may be an extreme example but there are a lot of projects that have more paid opportunities than Debian, e.g. Mono, GNOME, OpenOffice/LibreOffice and KDE. Obviously, there are some Debian Developers who can spend some time on Debian as part of their job. I know that some Canonical employees contribute to Debian, that support companies like credativ improve Debian as part of their work, and that system administrators fix bugs or package new software as they deploy Debian. But I think this is a minority of contributors and even they don t work full time on Debian. Instead what I see is that a lot of people leave university, get a job and then no longer have time for Debian or people start a family and no longer have time. I can take myself as an example since I don t have nearly as much time as I did in the past when I was a student. I guess there are different ways to deal with this problem one would be to create more paid opportunities around Debian outside the project, another one might be to make it easier for new volunteers to join the project. I don t have the answers to these questions but it s something I wonder about, and I also wonder whether pure volunteer projects can still keep up with projects with a lot of full time contributors. Raphael: What motivates you to continue to contribute year after year? Martin: Debian is a great project with a great mission, goals and people. I contribute to make Debian a better solution and to promote the free software philosophy. Finally, the community around Debian provides a lot of motivation. It s amazing how much I ve learned about other cultures because of my involvement in Debian and how many friends I ve made over the years all around the world. Raphael: Do you have wishes for Debian Wheezy? Martin: Not really. I m pretty happy with the way things are going at the moment. We have made a lot of organizational changes in the last few years from which the project has greatly benefited. I m particularly pleased about the plans to adopt a time-based freeze. Raphael: Is there someone in Debian that you admire for their contributions? Martin: There are many people I admire greatly. I d like to mention Joey Hess because he s a great example to follow. He doesn t get involved in politics, is easy to work with and does great technical work. In fact, he has made not one but several contributions that have completely changed Debian (debconf, debhelper, and debian-installer). Furthermore, Debian has a lot of contributors who have done great work over the years but who are not very vocal about it. People like Colin Watson or Peter Palfrader. Debian has many unique contributors and the list of people I admire is much longer than the few people I just mentioned.

---

Thank you to Martin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. He raised some interesting questions. 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, Twitter and Facebook.

No comment Liked this article? Click here. My blog is Flattr-enabled.

debconf riding is again After ~1650 km of motorbike riding from Paris, yesterday evening I've arrived at DebConf11, after having shared the part of the trip from Geneva to Banja Luka with my good friend gismo. The venue looks great. It's full of nice spots for impromptu chats, beers, and the like, which I love. I had a good lengthy recovery sleep and I'm ready for the usual DebConf fun to begin. Plan for today is simple: dismantle DPL backlog accumulated during the trip and in the frantic 10-15 days before it. If you are at the conference and willing to discuss, chat, or simply share a beer: do not hesitate! For something less informal, Neil is also organizing an in person "ask the leader" session here; feel free to propose questions to him and make me have a hard time answering them. See you around.

And Now For Something Completely Different There are those weird coincidences that flock together and have the power of subverting initial expectations. Something like that has happened to me this week, when I've ended up spending a considerable amount of my IRILL work time (you know, something like 1000% of it) as a Debian Video Team volunteer. Mean as I am, I'm not going to explain the concatenation of coincidences. Suffices to say that most of the video hardware meant to be used at DebConf11 ended up being in my IRILL office. Of course all of it for about 200 kg and 2000 liters was in need of some inventory, packing, and shipment love. Together with Holger, Mehdi, and Etci we have tamed all of it. The following box miscellanea will therefore soon be on its way to Banja Luka:

DebConf11 video hardware

As an undesirable side effect, I had to join Bdale's knows more about ATA than he'd like to -club.
Holger opted not to join the club and I really can't blame him.

Since my last report, a lot of visible changes have been made. First, if you edit the value of any of the text inputs on the dashboard table, your changes will be saved when you hit the submit button. This feature still needs a bit of work though. For example, I noticed during testing that if you submit the form multiple times, you will sometimes end up with approximately duplicate entries in the changes file (the file that stores user-submitted changes to the table). I also need to implement some checks to ensure that the values submitted are actually valid (i.e. we probably only want to allow a few possible values for the status column). Another big improvement is the addition of a graph at the bottom of each project s page. This graph tracks the number of open tasks versus time. The graph is re-generated once each day based on a progress file. This file simply lists a date and the number of open tasks on each line. While the graph does correctly show a line tracking the progress, it still has some issues to sort out. For example, the x-axis does not properly display a time increment. Work on the graph was blocked for a while due to not having a fully-functioning dashboard. Now that the dashboard is functioning, I should be able to start working on fixing these graph issues. Several people approached me to request the ability to link directly to a particular project. That way, users do not need to mess around with the select boxes. Above each table is a title. If you click on the title, the URL should update to link directly to the project. This is done with the distro and project query parameters. For example, a link to dex.html?distro=ubuntu&project=ancient-patches will take you directly to Ubuntu s ancient-patches project. Attempting to specify an invalid distro or project will cause the query parameters to be ignored. While looking at the table title, you will also notice a new (Graph) link. This link will take you directly to the bottom of the page so you can view the graph. Currently, it is not possible to link directly to the graph anchor tag of a specific project. Attempting to do so will cause the #graph portion of the URL to be ignored. However, if you click on the actual graph, it will load a full-size graph.png that you can link to. One rather significant issue that has shown up is that the table is very wide. On most monitors, you will have to scroll horizontally to view all of the columns. This is due to the fact that most of the cells are made up of text inputs (they don t have a background or border, but if you click on some text in the table, you should see the box) rather than plain text. The size parameter for a text input was meant to specify how many characters should be visible. However, while I have the size parameter set correctly for each input, it is showing up much wider than the text. I will continue to play around with this, since excluding the size parameter results in some values getting cut-off. As mentioned in my last report, I have continued to work with Allison Randal to make the dashboard more useful. I have received feedback directly from her and indirectly from other people working on the python2.7 project. During my last phone call with my mentor, Stefano Zacchiroli, we agreed that it would be very helpful to spend some time documenting how to go about adding a new project to the dashboard and how to utilize all of the dashboard s features. The goal of this is to not require people to go through me or any other individual to be able to use the dashboard. So while the Summer of Code is meant to focus on programming, I will probably spend some time adding some documentation, as a program is rather useless if nobody knows how to use it. Another bug that I will be working on has to do with sorting the table. I had this feature working early on in the project. However, the sorting broke when I starting using text inputs instead of plain text. I have done some research, and I hope to get the sorting re-implemented in the near future. One other feature that has been requested by several people is the ability to hide completed tasks. This has been on my todo list for a while. Matt Zimmerman wanted to take this a step farther. He felt that the status of the task should be separate from the bug. This means that you can have an open task with a closed bug or a closed task with an open bug. The user could then have some more control over what data they are seeing. I will probably attempt to add some check boxes to control whether certain information is displayed. The user will also be able to specify this directly in the URL. This means that a team could link directly to all open tasks in a project. It is also worth noting that thanks to some help from the fantastic Alioth admins, I now have a live instance of the dashboard running on Alioth. While the URL might change in the future, I hope to keep it running on Alioth. If you are interested in helping out with DEX or dextools, my code is available in a git repository on alioth. You can also join the debian-derivatives mailing list, join #debian-derivatives on OFTC, or contact me directly via email or on IRC (nhandler).

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (195 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dropbox for Debian This is not free software but Dropbox is very popular and they did only provide an Ubuntu package that did not work on Debian. So I created an official package. I have been in touch with Dropbox developers and they have been very helpful. They ll shortly release a signature mechanism (with GPG) so that we can further improve the package by verifying the origin of the downloaded binaries. SAT Britney At the start of the month, I continued my work on the britney reimplementation (the software that creates testing out of unstable) but I quickly stalled it because the release managers asked the feedback of Stefano Zacchiroli and Ralf Treinen (who have extensive knowledge on the topic with their research work on Mancoosi) and I did not want to invest further work in case they would identify a major flow the feedback came only very late this month and while it was somewhat negative, I still think it s worth pursuing the effort for a bit longer. Converted ftplib to multiarch While dpkg still doesn t support multiarch (no news from Guillem and no visible sign of progress ), unstable got all the remaining bits allowing us to convert libraries to multiarch (see the announce). As soon as the required libc6 landed in unstable, I looked into converting the only library package that I maintain. I had no major problem but I still identified 2 issues in Lintian (filed as #630164 and quickly fixed by Niels Thykier). build-arch / build-indep support For the 42th time in the last 10 years, the idea of using build-arch/build-indep targets in the rules file has surfaced again. I had already decided some time ago that I would accept a patch implementing a new field Build-Features to enable dpkg-buildpackage to use those targets and this time Bill Allombert completed such a patch so I merged it. The technical committee also decided that it would take a final decision on this topic (see #629385). Roger Leigh provided useful input by doing an archive-wide rebuild with the various solutions suggested. Given that the majority would like to make the target mandatory at some point in the future, I provided the dpkg patch for my preferred solution. We would use auto-detection as a temporary measure until all packages have been converted to have the targets. The technical committee has not yet taken any decision even though the discussion stalled since the 12th of June. But that s usual with that body. I m sure it will be solved during Debconf. Misc dpkg work

• Modified dpkg-source --after-build to automatically unapply patches if they have been applied by dpkg-source --before-build.
• Lots of small bug fixes (#628726, #629582, #630996, #631435, #631439, #631547, #632168) and that s just to keep with the flow of incoming bug reports!
• Added 2 supplementary Perl modules to the supported API for the benefit of Lintian.
• Spent an evening to track down the possible causes of an long-standing and annoying assertion failure related to triggers.
• Updated my branch with improved triggers directives to take into account the feedback of Guillem, and merged it.
• While doing this I discovered a design flaw with the usage of prerm failed-upgrade and merged a fix.
• Discussed integration of dpkg-buildflags with debhelper in #544844 and decided of further improvements for dpkg-buildflags as a result.

Hamster applet update Hamster-applet is a GNOME application which did not have a 3.0 release, but it had a development release (2.91.x). I checked out whether it was possible to package this version for experimental and have the applet work with the GNOME fallback mode. Apparently not, the code was not yet updated to be compatible with the newer panel. Instead I uploaded the latest stable version (2.32.1) to unstable. It has some nice improvements in the standalone version (and the name of the executable changed). For usage with GNOME 3, I have created a custom shortcut to start it quickly (with gconf-editor set /apps/metacity/global_keybindings/run_command_1 to <Mod4>t and /apps/metacity/keybinding_commands/command_1 to hamster-time-tracker because the GNOME 3 control panel does not seem to work to set custom keybindings currently). Translated my professional website into English While I m grateful for all the people who are supporting my work, I m still far from my goal to have one third of my time funded through donations and sales of products on this blog. So I decided to also bring more visibility to my company and in particular to its Debian-related service offering. It was only available in French up to now so I translated it and expanded it a bit. My support page on this blog now also links to my company s website. If your company needs help to create Debian packages, or needs Debian technical support by email, you just found the right partner. BTW, I have discounted prices for individuals and non-profits who would like to benefit from my help to create Debian packages. The Debian Administrator s Handbook This is the title of the upcoming translation of my book. The project now has a dedicated website: debian-handbook.info. You can subscribe to its RSS feed to keep up with the latest news. The full table of contents is online along with a FAQ. I m actively looking for partners to help me promote the fundraising once it goes live. If you can reach a large set of readers interested by a good Debian book, get in touch with me to join the affiliate program. Thanks See you next month for a new summary of my activities.

No comment Liked this article? Click here. My blog is Flattr-enabled.

Debian/Society at DebConf11 For DebConf11 which, needless to say, I'll be attending I've accepted to coordinate the Debian/Society track, together with dkg. As it's Daniel who has done most of the work up to now, let me pretend I'm catching up with a brief but very important call for papers. The idea of the Debian/Society track is to collect talks and other events that explore two society-related aspects of Debian:

1. Debian is a society in itself. It is a society formed by a group of people that are connected by relationships, share a (virtual) territory, and are subject to various kinds of self-imposed rules (technical, political, etc.)
2. Debian relates with larger human societies and has an impact on them, mainly but not only through the Free Software artifacts that Debian produces and distributes.

Several talks and events that have already been submitted to DebConf11 do a very good job at presenting one or both of the above aspects. But we are looking for a few more. In particular, we would like to receive submissions of events about:

• Governance models of other FOSS projects, possibly in a compare and contrast way with respect to how we do things in Debian. Are you a member of some FOSS project other than Debian and have given some thought about how well its governance mechanisms work in comparison to Debian's? Are you a geek about FOSS project management and have spent time thinking about how to improve Debian governance, transparency, or the like? We would like to hear from you!
• Impact of Debian activities on the "real" (non-geek) world. Do you have a good story to tell about how Debian has changed your world, or even a small part of it? Are you involved in some Debian (sub-)project which has the ambition of making the world a better place? We would like to hear from you!

If you think you can host the event we are looking for, just head to penta and submit your event providing all associated information (event kind, title, abstract, etc.). Please e-mail me or dkg when you've done so. We're way past the general event submission deadline, but if your proposal is just what we need to fill out the track, we can lobby the Talks Team for its acceptance (we can't guarantee acceptance, though). Daniel Kahn Gillmor
Stefano Zacchiroli

LDAP's "Country" entry reads "France" The correlation among quiet times for a blog and quiet times in its owner's life is often negative. My past two months are no exception. Beside my regular Debian activities, I've used a good chunk of my day time to (try) settle down and stop wandering around Europe, one temporary academic position after another. In the end, it has turned out very well. Starting September 1st, I'll be joinining the PPS laboratory as a Ma tre de Conf rences, a tenured academic position roughly equivalent to US' Associate Professor (at least according to Wikipedia; see the high quality references that tenured people resort to use?). More specifically, I'll continue to work in the context of IRILL (Research and Innovation on Free Software), an exciting new entity that I've helped bootstraping over the past couple of years. Thanks to IRILL and to his director Roberto Di Cosmo, I've been able not only to pursue quite some research on FOSS distros, but I've also been supported (rather than discriminated) in my Debian activities, including acting as DPL around the world. Last but not least, within IRILL I have also been able to offer support to several Free Software communities such as: Debian itself (hosting Sprints and sponsoring DebConf hardware), GNU, OSI, OCaml, Darcs, and many others. I realize how lucky I've been ending up in a place like IRILL and I'm glad to know I'll be around here for quite some time. The main change I'll expect to happen from September on is that I'll get back to do some teaching, trading-off time from research activities. I've been teaching only on and off since I've moved to France in 2008 and I miss that quite a bit. It looks like that next year I'll be teaching various classes on FOSS-related (or at the very least UNIX-y) topics. Time looks scarce, but who knows, maybe I'll also find a way to mix-in the nice packaging tutorial that Lucas has recently put together. Wish me luck!

A lot of work has taken place since my last report. First, since my original mentor, Matt Zimmerman, is going to be moving, he helped arrange for Stefano Zacchiroli to fill in for him temporarily. I have had a call with Stefano, and I am looking forward to getting to work with him more over the next couple of weeks. Shortly after my first report, we realized that having the dashboard only display bugs severely limited its usefulness. In our original design, we had it pulling a list of bugs with specific usertags from the BTS. This forced all information to be added to bugs, which we viewed as a good thing since it made the information available to the Debian Maintainers without requiring them to familiarize themselves with DEX. The issue was that when looking back at the ancient-patches project or forward to the big merges project, a large portion of the work will be triaging and determining whether or not the changes are even applicable in Debian. If they aren t, there is no reason for a bug to be filed on the BTS. As a result, I spent a fair amount of time re-writing most of the dashboard. It still supports finding bugs on the BTS that have been tagged with a specific DEX usertag, but it is now task-based rather than bug-based. A task can be a bug number, a package name, a patch name, or anything. It is merely something that needs to be done for a project. Each task will have a name, an assignee, a status, a note, and a bug associated with it. There are two ways to define a list of tasks for a project. The first is to tag bugs on the BTS with a user of debian-derivatives@lists.debian.org and a tag with a format of dex-<distribution>- <project> (i.e. dex-ubuntu-ancient-patches). The script will convert the bugs to tasks and automatically set all of the fields. The second method is to specify the list of tasks in a plain text file on the server the scripts are being run on. Eventually, this list will be able to be specified via a web interface. Currently, you are only able to specify the task name in the file. This means that all of the other fields for a task created in this manner are initially blank. I am still deciding on the best way to specify additional information about each task in the file. Once I decide on a method, it should not be too difficult to modify the script to parse and store that additional information. For the ancient patches DEX project, everyone involved had to update a status file stored in a VCS on alioth. This was rather annoying, so we decided early on that we want to be prevent this from being necessary for future projects. This means that the dashboard needs a way for users to modify the information on it. For tasks that are based on bugs, this is rather easy; you simply use the BTS email interface to adjust the bug. However, for other tasks, we needed the ability to modify them on the dashboard. I have managed to get this partially implemented. Currently, all cells on the table are text input fields (with css being used to hide the boxes). This means that you can click on any cell and edit its contents. Hitting the submit button will execute a script to save these changes. This is the tricky part. The dashboard is a collection of html files generated by a python script. The script is meant to be run by cron every n minutes. When you update something via a web interface, you usually expect to see the changes instantly. This means that we can t wait for the python script to run again and re-generate the html files. As a result, I currently have it setup so that when you submit the form, it will go and modify the html files to reflect the changes. The next time cron runs the python script, the html files will be re-created, and the changes made by the user will be lost. Once I come up with a method for storing additional information about a task, it shouldn t be too hard to make changes made by a user via the web interface permanent. I also did some work on a script to generate graphs. There are two types of graphs I hope to be able to display on the dashboard. One graph will help show which individuals have done the most work on a project. I have not started working on this graph yet. The second type of graph is meant to show the number of open tasks versus time. This will allow people to quickly see the progress of a project, estimate how long the project will take to complete, and notice if things start to slow down. I have some initial code for this graph using matplotlib. However, due to the many changes that were made to the dashboard, I had to hold off a bit on this graph, as it relies on certain information provided by the dashboard. I hope to sort out some of the last few issues with this graph, such as getting the axes to display properly, and then merge it with the dashboard sometime in the next few weeks. Allison Randal approached me a while ago to see if my Summer of Code project might be in a state where it could be used to assist with a Python 2.7 DEX project that she was working on. For a while, I did not think that it would be ready. However, last week, I helped her get the related bugs usertagged appropriately, and they now show up in the DEX dashboard. While the dashboard is still not complete, it does allow her and everyone else working on the project to clearly see the tasks (bugs) that they need to focus on and the current status of each of them. I plan to try and incorporate any feedback I receive from people working on this project into my designs. All of my code is available in a git repository on alioth. Keep in mind that it should not be considered stable at this point. Further status updates will be posted on my blog, and I will try to keep the wiki page updated. I am still trying work out where we will host the actual dashboard. In the meantime, you can try out my testing version of it. During the next few weeks, I will be focusing my efforts on coming up with a method for storing additional task information. That will allow me to support permanently storing changes made by users via the web interface. I also hope to finish the first graph script and merge it with the dashboard. Finally, I hope to find a permanent home for the dashboard, as having it on my personal server is not a viable long-term solution. Finally, if anyone is interested in getting involved with DEX, feel free to join the debian-derivatives mailing list, join #debian-derivatives on OFTC, or contact me via email or on IRC (nhandler).</project></distribution>