[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Branden Robinson's Platform for Debian Project Leader -- 2002

Since Raphaël did posted his platform in text form here, I guess I'll
follow suit.

         Branden Robinson's Platform for Debian Project Leader -- 2002

Introduction and Biography

   Greetings, fellow Debian developers.

   The purpose of this message is to outline the reasons I am running for
   Debian Project Leader (DPL), and to present an idea of some specific
   things I would like to accomplish during my term, if elected.

   First, a brief biographical introduction is in order. My name is
   Branden Robinson; I have been a Debian Developer since approximately
   January of 1998. My most prominent work in Debian has been as
   maintainer of the XFree86 packages, which I have done since March of
   1998. Since August of last year, I have also been the Treasurer of
   Software in the Public Interest, Inc., Debian's legal parent
   organization and manager of the Debian Project's assets. I am 27 years
   old, employed as a free software developer, married, and have no

   Some of this platform may be familiar to you if you have read from my
   DPL Platform from last year. This is because some of the issues I was
   concerned about have not been addressed in ways that I'm completely
   happy with.

   I will also note that there are few specific courses of action in this
   document to which I am wedded. The purpose of this document is to
   identify my guiding principles and priorities, not to draw a roadmap
   which I will follow in excruciating detail. Since I feel that a
   diagnosis of problems is less valuable without proposed solutions, I'm
   suggesting possible solutions. I look forward to interested people
   stepping forward and participating in the process of solving these
   problems. To me, leadership means listening, and then taking action on
   an informed basis. If you feel that some of my proposals suffer from a
   lack of information, I urge you to waste no time in bringing me up to

   Unlike some, I firmly believe that Debian's democratic, constitutional
   basis is a sound one. I do not believe it retards our growth or
   viability as a software project. On the contrary, I think that by
   distributing the lion's share of power among the Developers, rather
   than vesting it in the Project Leader, the Debian Constitution ensures
   our Project's long-term prosperity. It protects our Project's identity
   and goals from being excessively over-identified with a single
   individual. In the Debian Project, you shouldn't ever have to worry
   about what happens if developer X "gets hit by a bus", or -- more
   likely -- resigns (whether formally or by simply vanishing without a

   That said, the role of Project Leader is still an important one. The
   DPL must have an awareness of the challenges that face our Project
   which are too large for any one Developer to surmount, and attempt to
   allocate resources towards overcoming those challenges. At the same
   time, the Project Leader must maintain Debian as an environment that
   encourages experimentation, novel problem-solving, and reinforcement
   and reward for the volunteer spirit that is the backbone of our
   Project. Debian is an organization where one can simply leave if one
   is unhappy, so a Project Leader must do more than simply give lip
   service to consensus-building. The Debian Project does not have a
   captive membership; poor leadership will lead to loss of people, loss
   of vitality, and loss of relevance.

Major Issues

   The following is a list of items that will be high on my priority


   The central -- and overriding -- issue to my mind about the role of
   DPL is the process of delegation under the Constitution. I think this
   is a great mechanism (potentially) that has been underutilized to

   First and foremost, I think we need more delegates from the Project
   Leader. For the most part, Debian Developers have very narrow bounds
   within which they can exercise their personal discretion. This is,
   largely, the right way to do things. Since we are such a large body,
   and since we invariably have such a large pool of varied opinions
   about how any particular thing (technical or otherwise) should be
   done, this helps to keep Debian harmonious. In other words, we may
   argue, but there is a fairly clear perimeter within which any
   individual developer can act with a legitimacy recognized by the rest
   of the Project. This perimeter is pretty much confined to the details
   of maintaining packages.

   However, the larger issues of administration and coordination are
   often neglected; sometimes because there is no one to do them, and/or
   because no one has a clear mandate to act upon them.

   This is where I think the Debian Project Leader is required to act;
   indeed, I consider this to be perhaps the central duty of the DPL.
   And, moreover, not to personally and directly act upon the problems of
   the day, but to delegate responsibility for these duties. The days are
   long gone when the Project Leader could fulfill many administrative
   tasks himself; instead, the DPL must identify knowledgeable,
   dedicated, and willing people already within the Project to handle the

   I am confident that we don't presently have enough delegates, since
   there are many things that need to be managed that presently are not,
   and which are not properly within the decision-making authority of any
   individual developer as such.

   I would like to see greater formalization of the delegate status. As a
   first approximation, I believe there should be a webpage on the Debian
   site that not only enumerates them, but describes each one's duties,
   and stating the date each one began. Delegates should serve for a term
   of one year, or until the next DPL begins his term. I would like to
   think that in many cases, a delegate could continue to serve out his
   or her year-long term even across a DPL transition, but I also believe
   that delegates must derive their status from the sitting Debian
   Project Leader, since this only makes sense. It does not make sense to
   me for one DPL to be able to name a delegate, who then holds that
   position until resignation. Very little of the above is formalized in
   the Constitution. It either should be formalized in some official
   document, or a set of sound traditions should be established.

   Furthermore, I think that each delegate must be held to some standard
   of responsibility. The delegate must fulfill the role to which he was
   appointed, or be prepared to step down. The Constitution is clear that
   a delegate can be dismissed by the DPL for anything except a
   particular decision. It does not say say that the DPL cannot dismiss a
   delegate if that delegate isn't making decisions at all. Of course, if
   the Developers disagree, they can bring a General Resolution under the
   Constitution to put a stop to it (or recall the DPL himself). As DPL,
   I would publicly put delegates on notice that their inactivity is
   causing problems before withdrawing their status.

   At the very least, I believe the current DPL delegates of Project
   Secretary, Release Manager, Debian Account Manager, and Debian System
   Administrators should be completely formalized under this process. I
   also believe that it should be made explicit that delegates have the
   authority to sub-delegate, or nominate stand-ins for themselves to
   handle any duties already delegated to them if they are personally
   overwhelmed or otherwise busy.

   I believe that all existing DPL delegates, and the majority of Debian
   Developers, have the best of intentions, but are sometimes not good at
   recognizing when they no longer have sufficient time to dedicate to
   the tasks for which they have volunteered. Implementing policies and
   mechanisms for correcting this deficiency -- in a way that minimizes
   stress and conflict between developers -- is my top priority as DPL.


   Anyone who's been a regular in the #debian-devel IRC channel over the
   past few years will know that I've long complained that the Debian
   membership needs to be "reaped"; that is, we need to identify
   developers who are on our rolls but no longer really contributing.
   This is important because the core of our work -- our packages -- can
   end up in the hands of people who no longer have time for their Debian
   responsibilities, and thus we end up with parts of our distribution
   that are effectively unmaintained. This is even worse than having some
   critical piece of software unpackaged (consider, theoretically, the
   case if we didn't have a "bind" package), because by advertising the
   presence of a package, we are implicitly telling our users that we
   support it. Support means keeping it up-to-date, fixing bugs,
   coordinating with other developers to make sure it fits into the rest
   of the package structure in a clean and elegant way, and communicating
   with the users of that package. When a package is left unmaintained,
   none of these things happen. As we've seen over the past year, when
   critical packages go unmaintained in this way, our release process
   gets bogged down.

   Not to be ignored is the fact that inactive Developers on the rolls
   swamp our Constitution's Standard Resolution Procedure by artificially
   inflating the value of Q, making it difficult for quorum to be met,
   and action to be taken. This has the effect of falsely amplifying the
   influence of people who prefer the status quo. Not being around to
   even be aware of an issue under discussion is not the same thing as
   preferring that a General Resolution not come to a vote. See our
   [1]Constitution for more background on this problem.

   I am sympathetic to all kinds of reasons a package maintainer may be
   unable to contribute to the level required by the package, and the
   expectations of reasonable users. However, we must nevertheless be
   able to identify unmaintained packages and idle developers, and take
   appropriate steps to recognize their status as such.

   I propose that we experiment with, and ultimately apply, automated
   tools for tracking package and developer activity, and act
   accordingly. Idle developers should be moved into an "Emeritus" state,
   lose their Developer status under the Constitution, and have their
   packages distributed into the [2]WNPP system. There are already some
   tools in existence to handle the identification of idle maintainers,
   but I am less concerned with the specifics than with an effective

   Finally, I think implementing the above will go a long way towards
   addressing the "stigma" of Non-Maintainer Uploads (NMUs.) Right now,
   we have a great many packages in our archives that claim to have
   maintainers, but in actual fact, they don't. The maintainer may be
   otherwise active but neglecting a particular package, or the
   maintainer may simply not be participating in the Debian Project
   anymore. If we have ways of recognizing these facts, I think the
   fundamentals of our NMU procedures can remain unchanged.


   (By "functions" I mean any gathering -- typically, but not always, a
   "real-world" event like a trade show -- at which it would be
   worthwhile for Debian to have a recognizable presence.)

   This is one area where we've made some progress since last year;
   however, problems struck again anyway at LinuxWorld in New York and at
   the Annual Linux Showcase.

   Therefore, unless there is strong opposition, one of the first things
   I would like to do if elected Debian Project Leader would be to
   delegate, on a regional basis, Event Coordinators for Debian. These
   people would be responsible for keeping track of trade shows, major
   Linux User Group events, etc., at which Debian should have a presence.
   For each specific event, they would either handle contact with the
   coordinating entity directly, or delegate a person (preferably one who
   will be in attendance) to do so.

   One role that Event Coordinators can fill is that of handling
   complaints about exhibition controllers. USENIX was quite militant and
   almost extortionate in the way it treated non-profit booths at the
   Annual Linux Showcase last year. Even when we run our booth admirably,
   efforts by exhibition administration or sponsors to restrict access by
   non-profit groups -- especially with insidious methods like banning
   "outside" equipment and charging $130 for a table -- put a huge damper
   on Debian's ability to make itself visible to new users. Cash
   donations at booths also must not be ignored when considering Debian's
   revenue streams. Debian is funded entirely by donations; if
   exhibitions keep us off the show floor, they strangle us financially.

   As Debian Project Leader, I am willing to attend conferences and
   expositions, make presentations and speeches, and otherwise be a
   representative of the Project. I have public speaking experience and
   am happy to speak before an audience of any size.


   Here is another issue where substantial progress has been made since
   last year. However, in my opinion, this progress has been
   insufficient. SPI is in much better shape than it was one year ago,
   but there is still much to be done.

   As Debian Project Leader, it is my intention to recruit volunteers on
   behalf of SPI and attempt to grow the organization.

   As SPI Treasurer I am aware that there is a risk of a perceived
   conflict of interest if I am also elected DPL. I will do whatever is
   necessary to ensure that any such perception is unfounded and
   refutable. I think the appointment of a "shadow treasurer" who also
   receives all mail sent to the SPI Treasurer and to whom I CC all
   correspondence as SPI Treasurer (as it happens, I already CC the
   entire SPI board on such correspondence when functioning as SPI
   Treasurer) would help to achieve this.

   I am prepared to resign one of these two offices if the general
   consensus is that it is completely impossible for me function in both
   of these roles without jeopardizing either organization. However, I am
   confident that this is a problem that can be solved through
   accountability and visibility. It is my intent to resign as SPI
   Treasurer as soon as there are procedures in place to enable future
   Treasurers to do their jobs efficiently, rather than having to inherit
   headaches from previous Treasurers who may have neglected their


   The Technical Committee appears to have stagnated. There have been
   issues placed before the Committee and the Committee has failed to
   hold votes or otherwise reach conclusions on them. (Here is [3]one
   example, and here is [4]another).

   This is a serious problem because the Debian Constitution vests a
   great deal of authority in the Technical Committee. This body must be
   active and functioning. As DPL, I will exercise all powers available
   to me to ensure that the Technical Committee is able to execute its
   functions in a manner that is both timely and consistent with our


   This is a question that is practically inescapable. What can we do to
   get Debian GNU/Linux to release more frequently? Hundreds of kilobytes
   of armchair analysis and thought have been given to the issue on our
   various mailing lists. I'll be frank and say that I don't know that I
   have a definitive answer. Changing our policy on point releases of the
   stable distribution to include more than just security fixes and
   corrections for completely broken packages sounds like one part of a
   larger solution. As DPL, I'd like to invite Release Managers past and
   present, and other interested parties, to help a structure a new
   approach to release management.

   One thing I won't -- and don't want to -- do is yank the rug out from
   under the current Release Manager. Yes, the woody freeze has been
   taking a long time. However, it would, in my opinion, be folly to
   derail the process now, no matter how much some people are frustrated
   with it. Anthony Towns, the current Release Manager, needs your
   support. I'm very interested in hearing proposals for what we can do
   post-woody to make the release process less susceptible to friction,
   but right now the best thing anyone can do is to test fresh woody
   installs, test upgrades from potato, and find and fix release-critical
   bugs. If we hadn't made substantial progress on releasing I might feel
   differently, but we have. Anyone who feels that we haven't needs to
   review the [5]facts.

Lesser Issues

   The following are issues that I consider of secondary importance to
   the ones listed above. Nevertheless, they are ideas I have and I
   thought I would take this opportunity to enumerate them.


   Just as Debian has a Technical Committee, I'd like to see a body of
   legally-minded people formed who are empowered to render official
   decisions regarding the interpretation and application of the Debian
   Free Software Guidelines. As with the Technical Committee, of course,
   their decisions could be overridden by a General Resolution of the
   developers. The point is to get a formal structure in place for
   handing issues like this that don't require General Resolutions in and
   of themselves. GRs are a very weighty process, and where decisions of
   this nature can be made, it is good to have a mechanism for making


   When I first read the [6]DMUP I felt it was a poor fit in places for
   Debian. I was told that many of its terms were lifted verbatim from an
   ISP's Acceptable Use Policy (AUP). As DPL, I'd like to appoint a team,
   including at least one representative from the Debian System
   Administrators, to draft a new one that better reflects the nature of
   the Debian Developer as a creator of content, not just a consumer of
   bandwidth and other resources. I believe it is possible to keep the
   donors of our Project's bandwidth and rackspace happy without
   addressing our Developers as if they are hooligans. In my opinion, the
   current DMUP veers a little too far to the latter, and is worded in an
   overbroad manner in some places.


   Debian is a heterogeneous project; as such it affords a wide spectrum
   of political and philosophical beliefs among its membership.

   However, there are a few cases, especially with respect to
   intellectual property law, where a general consensus of opinion among
   Debian developers can be expected. Debian's profile is growing, both
   within the Linux community (as we continue to survive and thrive even
   as some other distributions reduce their scope or vanish altogether),
   and outside it, as the phenomena of Linux, GNU, and Free Software (or
   Open Source) appear with increasing frequency in international media.

   I think it would be a shame if Debian did not make an effort to lend
   its weight, however great or small, to specific political issues where
   it is important to do so. For instance, I imagine that Debian
   developers would be fairly united behind repeal of export controls on
   cryptography in the United States, and to support and reinforce recent
   initiatives in Europe to adopt Free Software at the governmental level
   as an act of public policy.

   As DPL, I would like to take steps to get Debian's voice heard in the
   halls of government if and where appropriate, so that our ideals --
   and our means of achieving them -- are not legislated out of existence
   by governments hostile to them (or, more likely, governments that have
   sold sections of their lawbooks to large corporations comfortable with
   past models of intellectual property and its distribution).


   A quick review of our [7]Social Contract reminds us that our
   priorities are our users and Free Software. In my opinion, we do the
   latter a little bit of a disservice by continuing to run the
   non-DFSG-free program qmail on the machine that hosts our mailing

   Our mailing lists are the lifeblood of our Project, and I think it's a
   shame that we might be slighting various fine -- and DFSG-free -- Mail
   Transport Agents (MTAs) through omission.

   In my tenure as DPL, I'd like to do whatever is feasible to transition
   official Project infrastructure away from non-DFSG-free software. A
   question in the business world that I've heard from time to time is:
   "Do we eat our own dog food?" -- meaning, of course, do we trust our
   own operations to the tools that we claim are sufficient for use by
   the rest of the world? I think the answer is: yes, we can -- but in
   some places, we don't. Not because we doubt the quality of the Free
   Software we devote our labor to, but because at some point in the
   past, the best way we could serve the needs of our users was to place
   our trust in a non-free tool. For our mailing list server, I believe
   that time has passed. Transitioning our list server is no small job,
   and doing so without disrupting our development process is a serious
   business. As DPL, I'd like to recruit volunteers to handle this task
   and prepare a schedule for executing a transition.

   As a Debian developer, I'm proud of the work that we do, and I see no
   reason not to trumpet the virtues of Free Software -- including its
   quality -- not just from the rooftops, but from our Received: headers
   as well.


   Thank you for your attention, and I hope this message has not been
   overlong. I welcome your feedback on my platform, and I strongly
   encourage you to vote in the forthcoming election.

   [8]Valid HTML 4.0! [9]Validate this page's HTML.


   1. http://www.debian.org/devel/constitution
   2. http://bugs.debian.org/wnpp
   3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=107150&repeatmerged=yes
   4. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=119517&repeatmerged=yes
   5. http://master.debian.org/~wakkerma/bugs/
   6. http://www.debian.org/devel/dmup
   7. http://www.debian.org/social_contract
   8. http://validator.w3.org/
   9. http://validator.w3.org/check?uri=http://people.debian.org/~branden/platform.html

G. Branden Robinson                |      It doesn't matter what you are
Debian GNU/Linux                   |      doing, emacs is always overkill.
branden@debian.org                 |      -- Stephen J. Carpenter
http://people.debian.org/~branden/ |

Attachment: pgpFfiOQWa0hj.pgp
Description: PGP signature

Reply to: