Bonjour, On 16/03/2014 18:45, jean-pierre giraud wrote: > Pas grand chose à redire. Quelques préférences personnelles > j'ai repris dans le diff la correction d'Etienne. Merci Étienne et Jean-Pierre, j'ai tout pris. Je passe le fichier en LCFC, merci d'avance pour vos dernières relectures. Amicalement, Thomas
#use wml::debian::template title="Platform for Lucas Nussbaum" BARETITLE="true" NOHEADER="true" #include "$(ENGLISHDIR)/vote/style.inc" <div id="header"> <h1 class="title">DPL Platform<br />Lucas Nussbaum</h1> </div> <h1 id="who-i-am-past-debian-contributions"><span class="header-section-number">1</span> Who I am â?? past Debian contributions</h1> <p>Incumbent DPL. French, 32 years old, Free Software user since 1997, <a href="http://en.wikipedia.org/wiki/Academic_rank_in_France";>Assistant professor (<em>Maître de conférences</em>)</a> of Computer Science at <a href="http://www.univ-lorraine.fr/";>Université de Lorraine</a> where I have the chance to teach Free Software and Debian in the context of a system administration curriculum.</p> <p>I started contributing to Debian in 2005. My main contributions, <strong>before</strong> my election as Debian Project Leader in 2013, are:</p> <dl> <dt><strong>Ruby.</strong></dt> <dd><p>I got involved in Debian by maintaining Ruby packages in the <a href="http://wiki.debian.org/Teams/Ruby";>pkg-ruby-extras</a> team. I co-maintained the interpreter packages, and initiated the work on our new packaging helper, gem2deb (= dh-make-ruby + dh_ruby), that makes it much easier to package Ruby software and significantly improved our relations with the upstream community.</p> </dd> <dt><strong>Collaboration with Ubuntu.</strong></dt> <dd><p>I worked on improving ways to manage divergence between Debian and Ubuntu, and to get Ubuntu improvements back into Debian. I contributed to a lot of softening in Debian/Ubuntu relations in the early years, to <a href="https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-August/000182.html";>policies such as the listing of the Ubuntu changes in Ubuntu changelog entries</a>, and added ways to get information about packages in Ubuntu with the <em>Ubuntu box</em> on the <a href="http://packages.qa.debian.org/d/dpkg.html";>Packages Tracking System</a>, and the Ubuntu column in <a href="http://qa.debian.org/developer.php?login=lucas%40debian.org&comaint=yes";>DDPO</a>. (read more: <a href="http://www.loria.fr/~lnussbau/files/fosdem2010-debian-ubuntu.pdf";>slides from a FOSDEM 2010 talk</a>)</p> </dd> <dt><strong>Archive rebuilds.</strong></dt> <dd><p>I had been rebuilding all packages in Debian on a regular basis since 2006. As a result, I filed over 7000 â??FTBFSâ?? release-critical bugs. Yes, I do feel bad about it, but I try to think of it as detecting problems early, not only as delaying releases ;). The same infrastructure was also used to test major migrations or toolchain changes involving gcc, <a href="http://clang.debian.net/";>Clang</a>, and Python. (more info: <a href="http://www.loria.fr/~lnussbau/files/fosdem07-auttest.pdf";>slides from FOSDEM 2007 talk</a>, <a href="http://www.lucas-nussbaum.net/blog/?p=718";>blog post about the more recent move to AWS</a>)</p> </dd> <dt><strong>Ultimate Debian Database.</strong></dt> <dd><p>Debian services (dak, wanna-build, BTS, DEHS, popcon, lintian, etc.) are very much heterogeneous in terms of technologies and interfaces. The positive consequence is that it is very easy for anyone to develop another service and get it integrated into our existing infrastructure. The negative consequence is that it is very hard to combine data. <a href="http://udd.debian.org/";>Ultimate Debian Database</a> solves that by importing all relevant data about Debian (and derivative distributions) into a single SQL database. Several services have been developed on top of UDD (including <a href="http://udd.debian.org/bugs/";>bugs search</a> and <a href="http://udd.debian.org/dmd/";>Debian Maintainer Dashboard</a>) and many others rely on UDD as a data source. (more info: <a href="http://www.loria.fr/~lnussbau/files/msr2010-udd.pdf";>paper</a> + <a href="http://www.loria.fr/~lnussbau/files/msr2010-udd-slides.pdf";>slides</a> at MSRâ??2010; <a href="http://www.loria.fr/~lnussbau/files/debconf9-ultimate-debian-database.pdf";>Debconfâ??09 talk</a>)</p> </dd> <dt><strong>Debian packaging tutorial.</strong></dt> <dd><p>I wrote a <a href="../../../doc/devel-manuals#packaging-tutorial">packaging tutorial</a> (<a href="http://packages.debian.org/sid/packaging-tutorial";><code>packaging-tutorial</code> package</a>) to provide a more accessible documentation for prospective maintainers. I used it to teach Debian packaging on a few occasions, and it has been translated into French, German and Spanish. It is also a nice way to advocate good practices, such as packaging with <em>dh</em> (slide 26), or first steps to get involved in Debian (get involved in teams / adopt existing packages, but not package more useless software when better alternatives already exist in Debian; slide 42).</p> </dd> <dt><strong>Misc.</strong></dt> <dd><p>I was marginally active in the Debian Science team. I have been an application manager in the NM process. On a few occasions, I also summarized huge threads on debian-devel@ (e.g. on <a href="http://lists.debian.org/debian-devel/2011/05/msg00111.html";>rolling</a>, and on <a href="http://lists.debian.org/debian-devel/2012/10/msg00469.html";>forced orphaning of packages</a>).</p> </dd> </dl> <p>(An overview of my first term as the DPL is provided in section 3.3.1 below.)</p> <p>Overall, most of my Debian contributions aim at addressing problems at the distribution scale (QA, data-mining), and at enhancing collaboration and communication (with new contributors, with derivative distributions).</p> <h1 id="state-of-debian-vision-and-general-goals"><span class="header-section-number">2</span> State of Debian â?? vision and general goals</h1> <p>Debian and distributions in general are probably at an important point of their history. After being the focus of a lot of attention for a long time, this focus is moving to other areas of the Free Software world. Of course, it does not mean that Debian is dying. It probably means that distributions have mostly solved the problems they were initially working on, and are now perceived as off-the-shelf components that just work.</p> <p>What should the Debian project do about that? Two things: get better at what we are already doing, and work on addressing additional important challenges of the Free Software world.</p> <h2 id="get-better-at-what-we-are-already-doing"><span class="header-section-number">2.1</span> Get better at what we are already doing</h2> <p>Debian is at the center of the Free Software ecosystem. It is the main active intermediary between upstream projects developing <a href="https://lists.debian.org/debian-devel/2014/03/msg00029.html";>more than 20,000 pieces of Free Software</a> and final users. It provides integration and robustness to the Free Software world. Those are great achievements, really, especially given the volunteer-based and community-driven nature of Debian. Also, Debianâ??s adoption and popularity are probably at its historical maximum: a lot of people care about what Debian is going, as shown by the coverage of the init system debates. But can we do better? Probably.</p> <p>In the post-Snowden world, we should <strong>improve the trustworthiness of our packages archive</strong> thanks to <a href="https://wiki.debian.org/ReproducibleBuilds";>reproducible builds</a> and <a href="https://lists.debian.org/debian-devel/2011/04/msg00840.html";><em>binary-throw-away uploads</em></a> (not using the binary package built on the Developer machine as the one that goes to the archive). We should improve the quality of our packages using more automated testing, using existing tools as well as the <a href="https://lists.debian.org/debian-devel-announce/2014/02/msg00010.html";>ci.debian.net infrastructure</a>.</p> <p>We should also continue to work on <strong>being a more welcoming project, both for our upstreams, for our derivatives, and for prospective contributors of all kinds</strong>. Debian is often perceived as an organization that is hard to grasp on both organizational (teams), technical (practices) and social sides. There are great initiatives such as <a href="http://patch-tracker.debian.org/";>Patch Tracker</a>, <a href="https://wiki.debian.org/DerivativesFrontDesk";>Derivatives Front Desk</a>, <a href="https://contributors.debian.org/";>Debian Contributors</a> or the <a href="https://www.debian.org/vote/2014/vote_002";>Debian Code of Conduct</a>, but thereâ??s a lot more to do to enable easier collaboration with individuals and organizations (e.g.; improving/simplifying development practices and documentation, developing mentoring initiatives, reactivating the quite dormant debian-companies@ initiative).</p> <h2 id="address-additional-important-challenges-the-debian-way"><span class="header-section-number">2.2</span> Address additional important challenges, the Debian way</h2> <p>Our role in the Free Software ecosystem should extend beyond being a solid distribution for others to base on: we should use our existing position and expertise to contribute to solving additional important challenges. Doing things the Debian way also increases the visibility and impact of Debian itself, and thus of the important values for which we fight for as a project.</p> <p>First, we should leverage Debianâ??s current status to <strong>improve the Free Software ecosystem as a whole</strong>. One good example is the <a href="http://debile.debian.net";>Debile project</a> (website currently down, <a href="http://france.debian.net/evenements/minidebconf2014/debile-presentation.pdf";>slides available</a>) that aims at performing Quality Assurance tests on the Debian archive: this contributes to improving the QA tools, the tested software (compilers, toolchain), and after fixing the detected problems, Debian. But we could go further, and imagine providing upstream library developers with an easy way to test candidate changes on all reverse-dependencies in Debian.</p> <p>Over the recent years, there has been a huge growth in the size of the typical stacks involved in infrastructure software (think of beasts like Cloud or virtualization stacks). They usually include dozens of intertwined packages, that often must all be configured in a specific way to work together. Our typical solutions to handle the configuration of packages work well for a single package, but are less suited to jointly configure several interacting packages. Thatâ??s where configuration management tools generally excel, even if the large number of competing such tools shows that thereâ??s no final answer to that question yet. How can distributions help <strong>facilitate the distribution of complex software stacks</strong>?</p> <p>A lot of usage is moving from traditional platforms (laptops, workstations, servers) to tablets and smartphones. Thatâ??s a world where free operating systems, especially Debian-based, are rather scarce. Of course, a major blocker is the limited availability of hardware platforms that donâ??t require patched kernels or non-free software. But thereâ??s still a long path before we will be able to <strong>run Debian on all our computers, from smartphones to servers</strong>.</p> <p>Addressing those challenges requires the project to <strong>be more welcoming towards innovation and experiments</strong>, even when they are only at the stage of half-baked prototypes. Often, we merely tolerate such experiments instead of encouraging them, judging them too early, which makes conducting them inside Debian harder and slower than necessary. We should also <strong>provide infrastructure to support those experiments</strong>, such as unofficial developer repositories (PPAs).</p> <h1 id="goals-for-a-new-term"><span class="header-section-number">3</span> Goals for a new term</h1> <h2 id="looking-back-at-my-current-term"><span class="header-section-number">3.1</span> Looking back at my current term</h2> <p>Becoming the DPL is like switching jobs. You discover that reality is a bit different from your expectations, and you get to learn a lot of stuff. There are really two sides to the role of the DPL. One is being an <em>administrator</em> of the project, making sure that the project stays in good shape, and smoothing the issues that make Debian frustrating. That involves many small tasks, but just to outline a few: I helped grow the <em>Trademark team</em>, which then initiated the registration of the Debian logo as a trademark. I <a href="https://lists.debian.org/debian-devel-announce/2013/06/msg00003.html";>revoked all old and inactive delegations</a> to create a <a href="https://www.debian.org/intro/organization";>clear picture of current delegates</a> (with the help of Moray Allan). I defined <a href="https://wiki.debian.org/Teams/DPL/TrustedOrganizationCriteria";>criteria for the evaluation of prospective Trusted Organizations</a> (with the help of auditors and DPL helpers).</p> <p>The other side of the role is to push forward and work on projects that are particularly important for Debian. For example, I did a <a href="https://lists.debian.org/debian-project/2013/08/msg00011.html";>survey of new (packaging) contributors</a> in order to better identify the main hurdles that one has to overcome when first contributing to Debian. Some resulting ideas are still to be implemented, but one main result was that, after a discussion with Asheesh Laroia at DebConf, I developed <a href="https://packages.debian.org/sid/how-can-i-help";>how-can-i-help</a>, a simple helper to highlight opportunities for contributing to Debian in locally-installed packages (featured in <a href="http://bits.debian.org/2014/02/how-i-can-help-package.html";>this bits.d.o post</a>).</p> <p>Also, even if thatâ??s really a minor contribution, Iâ??m quite proud to have proposed the <a href="https://lists.debian.org/debian-devel/2013/05/msg00496.html";>idea and a prototype implementation</a> for important/key packages, that evolved into something part of the <em>automated removal of RC-buggy non-key packages</em>, which I hope will help reduce the duration of the next freeze.</p> <p>Thereâ??s a lot more, of course, as described in my day-to-day log (<code>master:/srv/leader/news/bits-from-the-DPL.txt.*</code>), and in my regular <em>Bits from the DPL</em> (<a href="https://lists.debian.org/debian-devel-announce/2013/05/msg00002.html";>04</a> <a href="https://lists.debian.org/debian-devel-announce/2013/06/msg00000.html";>05</a> <a href="https://lists.debian.org/debian-devel-announce/2013/07/msg00002.html";>06</a> <a href="https://lists.debian.org/debian-devel-announce/2013/08/msg00002.html";>07</a> <a href="https://lists.debian.org/debian-devel-announce/2013/09/msg00002.html";>08</a> <a href="https://lists.debian.org/debian-devel-announce/2013/10/msg00002.html";>09</a> <a href="https://lists.debian.org/debian-devel-announce/2013/11/msg00000.html";>10</a> <a href="https://lists.debian.org/debian-devel-announce/2013/12/msg00003.html";>11</a> <a href="https://lists.debian.org/debian-devel-announce/2014/01/msg00005.html";>12+01</a> <a href="https://lists.debian.org/debian-devel-announce/2014/03/msg00001.html";>01+02</a>). Additionally, to increase the insight about what the DPL does and plans to do, I also made (most of) my TO-DO list public, and included it in my monthly reports, which I consider a nice step towards more transparency.</p> <h2 id="why-am-i-running-for-re-election"><span class="header-section-number">3.2</span> Why am I running for re-election?</h2> <p>That decision has not been easy to make. As I have already mentioned in the past, the workload involved in being the DPL is just huge. I was not expecting it to be light of course, but it was worse than I imagined: I know that if I do not spend 1.5 to 2 full days working on Debian per week, my backlog tends to increase. I must also admit that I feel quite hacking-deprived: I would love to be able to spend more time on technical stuff.</p> <p>But then, there are many more reasons to run again.</p> <p>The first one is that itâ??s about Debian, of course. We should all be very proud of what we are building together. I feel very honored to play such a role in such a great community. You are all great, really.</p> <p>Another reason is that I learned a lot of things during that year as the DPL, and it would not feel quite fair for me to leave now, without first giving back a bit more. There are some things which did not go perfectly well, too, and Iâ??d love to have an opportunity to do better.</p> <p>Finally, it seems that the init system debates are approaching an end (or at least I hope so). After those very difficult times for the project, I think that some stability could be useful, especially as we are in the middle of a release cycle.</p> <h2 id="specific-plans-for-a-new-term"><span class="header-section-number">3.3</span> Specific plans for a new term</h2> <p>If re-elected for an additional term, I would of course continue on the same path as during my first term (also applying the lessons learned from the things that did not work so well during that first term). However, there are also two specific areas where I plan to put a special focus.</p> <h3 id="building-a-better-understanding-of-debians-financial-status"><span class="header-section-number">3.3.1</span> Building a better understanding of Debianâ??s financial status</h3> <p>The status of Debianâ??s available resources, and of Debianâ??s annual budget, are a much more fuzzy status than we would like. As a result, questions such as <em>Can we afford to spend $amount on $project?</em> are very hard to answer. Together with the auditors team and our Trusted Organizations, I plan to work on improving the tracking of our revenues and our expenses, so that it is possible to build an annual Debian budget, at least approximate. There are other upcoming tasks in that area, such as improving our overall donations infrastructure, and our reimbursement processes. The expected outcome is that, by working on those issues now, we will facilitate making a lot of money-related processes and decisions later: use Debianâ??s financial resources to sponsor more sprints, buy better infrastructure, solve problems that cannot be solved in another way.</p> <h3 id="achieving-sustainable-governance-in-debian"><span class="header-section-number">3.3.2</span> Achieving sustainable governance in Debian</h3> <p>Our current model for Debian governance does not scale well, something that was also noted by e.g. Stefano Zacchiroli during his DPL talk at DC12 (<a href="https://upsilon.cc/~zack/talks/2012/20120708-dc12-dpl.pdf";>slides 22+23</a>). It requires finding someone who can dedicate a large amount of time to Debian during a full year, which restricts the set of possible candidates. The ideal DPL also would have a very diverse set of knowledge and skills (technical, accounting, legal, management) that are almost impossible to find in a single individual, but could be found inside a team.</p> <p>Various options have been proposed and sometimes tried over time: DPL team, second-in-charge, DPL helpers, etc. The DPL helpers initiative provided useful help with some issues, but was also disappointing on some aspects: (1) the amount of participating people was rather low (several meetings with two or three participants, which prompted me to stop organizing them since the beginning of 2014); (2) I donâ??t think that it provided much more insight about the DPLâ??s tasks to participants; (3) its setup prevented it to help with some aspects of the DPL role â?? for example, some behind-the-scenes discussions could have been helpful to get early feedback on ways to address specific issues, but thatâ??s difficult to do in a public discussion channel.</p> <p>I plan to try a different variation of the DPL helpers idea, that could be summarized as a <em>rolling board</em>: I plan to share private DPL information (such as email sent to leader@) with a set of Developers active on tasks from the DPL TO-DO list, and use that group as an advisory board to discuss issues and ideas before they can be discussed in a wider audience. I believe that this would be a solution for: (1) sharing the DPL workload; (2) increasing the awareness of DPL activities among possible future DPL candidates; (3) getting more feedback early, resulting in better decisions; (4) enabling participating in DPL activities from people who are unable to dedicate enough time to run for DPL themselves.</p> <p>Of course, there is the risk of creating a cabal, and of reducing transparency. I am absolutely committed to avoiding that. As an initial implementation, I would justify every month (probably as a note in the day-to-day log) who is part of that board based on activity during the previous month. In terms of privacy, the members of the board would receive emails sent to leader@, and an additional alias (leader-private@) could be created for information that should not be shared with the board. I am also committed to maintaining the same level of information about the DPLâ??s activities (day-to-day log, monthly bits emails). I would also like to point out that many of our core teams have private discussion channels (mailing lists or IRC), and that the private nature of this experiment is mainly a way to officialize what already happens when the DPL decides to include someone relevant in a non-public discussion, or consult someone in a private IRC discussion. In some sense, DPL helpers and the board would be similar to the public/private discussion channels of our core teams.</p> <h3 id="misc."><span class="header-section-number">3.3.3</span> Misc.</h3> <p>Of course, there are lots of other things that I would like to see happen (see <a href="https://wiki.debian.org/Teams/DPL/Ideas";>this page</a> for a list â?? some of them would require more discussion first). And I would surely work on them if I end up having the time. But after one term as the DPL, I believe that the two areas described earlier (better understanding of Debianâ??s financial status; sustainable governance) are really a must to provide a more easily manageable project for the future.</p> <h1 id="rebuttals"><span class="header-section-number">4</span> Rebuttals</h1>
Attachment:
signature.asc
Description: OpenPGP digital signature