The third of my reports as Debian Project Leader is now available. You
may read it in HTML format at:
http://people.debian.org/~branden/dpl/reports/2005-07-07.html
...or in ReStructured Text format[1], below. If you find ReStructured text
format difficult to understand, you can use lynx to dump a plain text
version of the URL above:
$ lynx -dump http://people.debian.org/~branden/dpl/reports/2005-07-07.html
I do make corrections for a few days after publishing these reports, so I
urge you to contact me if I have made any erroneous claims, or there are
editorial changes (spelling, grammar, etc.) that should be made to the
document.
[1] http://docutils.sourceforge.net/rst.html
Debian Project Leader Report for 2005-07-07
===========================================
I apologize for the lateness of this report. I pledged to make (at
least) monthly reports to the Project membership as leader, and though I
made two in my first month in office (on `24 April`_ and `8 May`_), it
has been nearly two months since the last one.
While I do not offer excuses, it is reasonable to wonder what I've been
doing with my time instead of writing reports. Apart from the
leadership activities covered below, I have been assisting David
Nusinow, Nathanael Nerode, Eugene Konev, and Julien Cristau in the
preparation of X.Org X11R6.8.2 packages (see most of the `traffic for
the month of June on the debian-x mailing list`_). I have also been
seeing to the health of my wife Michelle, who has been hospitalized
twice in the past month, and about which I will not say more here (I
don't wish to belabor this report with it, but you can feel free to ask
me in person, in email, or on IRC -- it's no secret).
I will strive not to let this lapse happen again.
As one might expect after almost two months, there is much to talk
about.
Sarge Release
-------------
While many of us rightly have our minds on new challenges, it bears
repeating that after months -- even years -- of agonizing anticipation,
we released Debian 3.1, a.k.a. "Sarge", one month ago. I sent a
`message of congratulations`_ to the `debian-project mailing list`_
shortly afterwards.
I remain proud of our release and our achievement in releasing it. It's
important to retain that sense of pride and accomplishment as we tackle
our future challenges. Any distribution that can survive having
`thirty different laptops thrown at it`_ in a pinch, and install to them
all, is one we can take pride in.
Status of Security Support for Released Distributions
-----------------------------------------------------
As has been covered in `the press`_ (also see `Joey Hess's commentary`_)
and in `Martin "Joey" Schulze's blog`_, Debian has been sluggish with
security updates for Sarge (and Woody, the previous stable release,
which we plan to support until June 2006).
I think it's worth pointing out to anyone who's not aware of it that
`security updates resumed at the end of June`_. Steve Langasek,
one of our Release Managers, informs me that all known issues blocking
the current round of security advisories have been fixed.
After extensive conversations with many people, I diagnose two factors
that led to this problem: 1) our failure to scale the security team in
line with the demands being placed on it; and 2) a failure of process in
making the security updates that *were* prepared release in a timely
fashion.
Javier Fernández-Sanguino Peña warned us of the first issue two years
ago, in his `"Security in Debian" talk at DebConf 3`_.
The security team has received offers of help, and I've been
carbon-copied on some of these. I have sent the Debian Security Team a
proposal for making formal DPL delegates out of its members; it seems a
ripe for updating the team's membership roster, as I understand some of
its personnel have been inactive for a while.
This leads us to the second problem. In my platforms for Project
Leader, I asserted that a lack of transparency and visibility of process
was a bad thing. I suspect, given what I know from conversation with
some of the principals close to the infrastructure involved in getting
our stable security updates out, that that's what we're dealing with.
There have been technical failures and communication failures, with the
former greatly exacerbated by the latter.
I have asked Andreas Barth to look into this situation and establish as
clear a factual record as he can. Using this report, we should be able
to attack the areas of weakness. One thing I'd like to see is better
documentation of the internal workings of the security update process,
perhaps in the `Debian Developers' Reference`_. With a broader
understanding of security workflow, I'm hopeful that people will be less
likely to draw erroneous inferences about what the causes of problems
are, and more likely to make offers of assistance that prove fruitful.
I expect to spend a lot of time talking about this issue to Debian
developers and representatives of our user community (including sponsors)
at `DebConf 5`_, the 6th annual conference of Debian Developers, held
from the 10th to the 17th of this month in Helsinki, Finland.
Many people have stepped forward in public or in private to offer us
assistance with ensuring that this problem does not recur, and that
Debian upholds its valuable reputation as a consistent provider of
timely security updates to its users. I regret the interruption of this
service, but with so many people determined to apply their skills to
this facet of our responsibilities, I'm confident that we can prevent
its recurrence.
Delegation activities
---------------------
On 23 June, I `established`_ a new set of delegates: the Package Policy
Committee. It has been years since technical policy affecting official
Debian packages was the province of the Project Leader. Old-timers
within the Project remember the original Debian Policy "czar", Christian
Schwarz. After Christian's departure from the Project, the
`debian-policy mailing list`_ was created to manage updates to the
policy manual.
The power of the maintainers of the Debian Policy Manual is substantial;
they have the power to mandate standards of behavior for Debian
packages, and a significant change to Debian Policy can render many
packages susceptible to the filing of release-critical bug reports (it
is a "serious" bug in the parlance of the `Debian Bug Tracking System`_
for a package to fail to comply with a Policy mandate).
The team of Debian Policy editors have also provided, in my opinion, an
excellent example of visiblity and transparency of process over the
years. Decisions are taken in public with the concomitant rationales,
disputes, and caveats all out in the open.
Due to the foregoing factors, I'm pleased to inaugurate the initial
members of the Package Policy Committee: Andreas Barth, Matt Zimmermann,
and Manoj Srivastava (chair).
I believe some of the lessons we've learned from the Debian Policy
editors can be fruitfully applied to other teams; accordingly, I have
sent mails to the package archive administration ("ftpmaster") and
Debian host system administration ("debian-admin") teams, as well as the
Debian Security Team as previously noted. In those mails I invited
feedback on my ideas for formalizing the delegate status of those teams
in a way that will prove beneficial to the Project.
I seek to accomplish three things in the delegation process:
* Define the role to be delegated, enumerating the powers granted;
* Assign personnel to serve in that role; and
* Explain to the developers and the general public how the delegates are
expected to interact with other teams and roles recognized in the
Debian Constitution, where the Constitution doesn't already provide
guidance. The interaction of various delegates who have intersecting
areas of responsibility is of particular concern to me.
Finally, it is also important to justify why a given delegation is being
made, and I hope I have done so above with regard to the Package Policy
Committee. For highly specific tasks, the justification is sometimes
obvious; for ongoing areas of responsibility, it can be more important
to explain the motivation for the decision. Because I feel formal
delegation has been underutilized by past Project Leaders, I expect many
of my delegations to simply recognize the existing realities of how the
Debian Project operates. I hope that the formaliztion framework I
described above will help us to achieve greater efficiency and reduce
the number of acrimonious arguments we have; time will tell if I'm right
and if we can build on that framework.
Hosting needed for ftp-master.debian.org and db.debian.org
----------------------------------------------------------
On 22 June, one of our host system administrators, James Troup,
`announced our need for a new hosting site`_ for the machines serving as
``ftp-master.debian.org``, which is the central package archive server
for the Project, and ``db.debian.org``, which houses our LDAP database
of developers and machines. If it wasn't already clear from their
description, the services provided by these hosts are critically
essential to our infrastructure. For years, hosting for these machines
has been graciously provided by `above.net`_, but now we need to find a
new home for them.
We haven't yet acquired a new long-term hosting provider. Therefore,
I'd like to put a call out to the Debian community for assistance.
These machines have a lot of demands placed upon them; hosting them is
therefore a serious commitment. Permit me to quote James's criteria
(with some editing)::
The hosting must:
* Be a donation, i.e. gratis. Debian cannot pay for its own hosting.
* Be in a managed facility with decent environmental conditions.
* Be on a UPS or otherwise have reliable power.
* Have response time for the local administrator measured in hours, not
days.
* Have very good unmetered bandwidth (i.e., >> 100Mbit and preferably
Gbit or better).
* Have good and reliable connectivity.
* Not have any enforced firewalling or proxying.
* Not be short term (12 months or better*).
* Be done with the knowledge and agreement of your employer or other
appropriate authority.
* (For ftp-master:) Be in the U.S.**.
Advantageous factors include:
* Being on or connected to Internet2.
* Having somewhere accessible to DSA to plug the iLO[***] into or,
failing that, having remotely controllable power-switch
capabilities.
* Not having shaped or (artificially) limited bandwidth.
Notes:
* Obviously, this is a donation, not an obligation, so this is just
the length of time you hope to be able to allow us to host the
machines with you.
** To avoid continuing issues with BXA export regulations, it makes
lives of U.S. developers easier if ftp-master is in the United
States. Technically, it'd be possible to work around having
ftp-master outside the U.S. (by relocating the NEW queue to a
machine in the U.S.), but it'd be a lot of work that I don't
want us to have to do unless it's necessary.
*** http://h200001.www2.hp.com/bc/docs/support/SupportManual/c00257345/c00257345.pdf
If you can help the Debian Project out in this area, we would
`appreciate it`_. Please contact the Debian host system administration
team at ``debian-admin@lists.debian.org``, and feel free to contact me
at ``leader@debian.org`` as well.
Replacements needed for klecker.debian.org and costa.debian.org
---------------------------------------------------------------
In my `previous report`_, I mentioned that we needed replacements for
two of our machines, ``klecker`` and ``costa``. ``costa`` provides
the official `Arch`_ and `Subversion repositories`_ for the Debian
Project, and ``klecker`` hosts the main `Debian website`_.
Unfortunately, the source we thought we originally had for replacements
for these machines is not going to be able to help us very soon. As
with hosting, then, I call upon the Debian community to help us out.
``costa`` is a dual Intel Pentium III 866MHz with 1GB of RAM and 127GB
of RAID5 storage. ``klecker`` is a dual Intel Pentium III 700 MHz box
with 512MB of RAM and four 18GB drives.
Since both of these machines are suffering from disk and memory resource
limitations, we'd prefer the replacement for ``klecker`` to have
2GB of RAM and 200GB of RAID with a hot spare disk, and the replacement
for ``costa`` be a dual-CPU machine with 2GB of RAM and 500GB of RAID
with a hot spare disk. Exceeding these parameters is perfectly
acceptable. :)
Hosting considerations mean that these must be rack-mountable machines,
with the additional constraint that ``costa`` is limited to a maximum of
5U in size.
If you can help the Debian Project out in this area, we would
`appreciate it`_. Please contact the Debian host system administration
team at ``debian-admin@lists.debian.org``, and feel free to contact me
at ``leader@debian.org`` as well.
Mozilla Firefox trademark license
---------------------------------
On 25 June, Eric Dorland contacted me with concerns over the Mozilla
Firefox trademark policy. I had an involved coversation with him and
Matthew Garrett regarding this and related issues, and we reached a
consensus. We believe the grant of permissions at the end of `Gervase
Markham's 14 June reply to Thijs Kinkhorst`_ on the `debian-devel
mailing list`_ are sufficient as long as that grant of permission to use
the mark is truly irrevocable (we can't "unrelease" a package, even to
``unstable`` or ``experimental``. What we can do is make our best
effort to replace broken packages with fixed ones, respect the wishes of
our upstream, and fork when we must disagree). Matthew Garrett has
discussed this with Gervase Markham, and it was Matthew's impression
that Gervase felt this was feasible.
I view trademarks managed in this nature as very similar to "endorsement
clauses", which I discussed with Joe Wreschnig and others on the
`debian-legal mailing list`_ about three years ago. In a nutshell, a
permission grant to use a trademark works much like an endorsement
(e.g, "I'm Branden Robinson, and I approve this package!"). It attaches
to, and in a way authenticates, specific sequences of bits, like a
digital signature (but somewhat more vaguely). If someone changes that
bitstream, they cannot assume it is still endorsed absent a statement
from the endorser (or trademark holder). However, once granted, the
endorsement of a given bitstream cannot be revoked -- it doesn't matter
who distributes it.
Under these conditions, we, and our users, retain the essential right to
fork. We can decide to take the Mozilla Firefox codebase and replace
the marks within it with references to frost-encrusted mustelidaeans.
Within limits that unfortunately vary by jurisdiction, we can claim
derivation from, similarity to, or compatibility with Mozilla Firefox.
(We could also skip the issue by letting the browser's user interface
speak for itself -- the basic UI of the graphical web browser hasn't
changed much since NCSA Mosaic over ten years ago.)
The other essential point is that we, the Debian Project, must not put
ourselves in an advantaged position over our users when it comes to
licensing. That, to me, is the spirit behind section eight of the DFSG.
We already enjoy many advantages concomitant to our reputation as a
large and prosperous Free Software project. Our dedication to the
community entails that we keep in mind what we needed when we were a
small, feisty organization that nearly no one had heard of, and that any
pundit in the IT press would have written off as irrelevant.
Miscellaneous items
-------------------
* The DebConf 5 budget is about USD 36,000. Andreas Schuldei won't have
the final budget numbers until after the conference happens --
people who had sponsored travel expenses but have to cancel their
attendance won't be reimbursed, for example.
* I have approved the reimbursement up to USD 2,275 in travel costs to
send Isaac Clerencia, Adeodato Simó, and Christopher Martin (members
of our KDE packaging team) to `aKademy 2005`_, the annual conference
of KDE developers.
* According to the draft annual report prepared by President John
Goerzen, `Software in the Public Interest, Inc.`_ (SPI) now holds over
USD 50,000 in assets for itself and its member projects -- most of
this amount is earmarked for Debian. (The final version of the report
`may be available`_ by the time you read this.)
* Some people have expressed concerns to me that the
`debian-announce mailing list`_ and the Debian Press Contact role are
under-utilized. I'd appreciate hearing more views on this.
* I was unable to attend `FISL 6.0`_ because the office of the Brazilian
Consulate General did not approve my visa application in time for me
to travel. In fact, it arrived the day *after* the last possible day
it could have done me any good. I apologize to all of the FISL
attendees who were expecting to meet with me and hear my presentation.
I hope to have another opportunity to travel to Brazil during my term
as Debian Project Leader -- there is much exciting work going on
there.
Conclusion
----------
I'm curious to know how you feel I am fulfilling my responsibilities as
Debian Project Leader. You can reach me at ``leader@debian.org``.
I will be at `DebConf 5`_ for the entirety of the conference. I
encourage everyone to walk up and say hello, and share with me any
concerns or thoughts you have -- good, bad, or otherwise. I cannot do a
satisfactory job as an elected leader and representative of the Project
if I don't know the minds of the developers, so I encourage everyone to
be candid with me. Do not be alarmed if you see me pull out a small red
device and speak into it after we've conversed; it's my music
player/audio recorder (an iRiver iFP-899). After DebConf 3 I decided I
needed a way to keep track of the many encounters I have at Debian
conferences. I find paper and pencil, PDAs and laptops all too
cumbersome for the rapid sequences of one-on-one discussions that often
happen at a conference. I just hope I don't turn into Ted Nelson. ;-)
----
:Author: Branden Robinson, Debian Project Leader
:Address: ``leader@debian.org``
:Webpage: http://people.debian.org/~branden/
``$Id: 2005-07-07.rst 192 2005-07-07 06:20:40Z branden $``
.. _24 April: http://people.debian.org/~branden/dpl/reports/2005-05-08.html
.. _8 May: http://people.debian.org/~branden/dpl/reports/2005-05-08.html
.. _traffic for the month of June on the debian-x mailing list: http://lists.debian.org/debian-x/2005/06/index.html
.. _message of congratulations: http://lists.debian.org/debian-project/2005/06/msg00128.html
.. _debian-project mailing list: http://lists.debian.org/debian-project/
.. _thirty different laptops thrown at it: http://kitenet.net/~joey/blog/entry/fi-2005-07-05-15-02.html
.. _the press: http://www.zdnet.com.au/news/software/0,2000061733,39200592,00.htm
.. _Joey Hess's commentary: http://kitenet.net/~joey/blog/entry/secfud-2005-07-06-11-28.html
.. _Martin "Joey" Schulze's blog: http://www.infodrom.org/~joey/log/
.. _security updates resumed at the end of June: http://lists.debian.org/debian-security-announce/debian-security-announce-2005/msg00117.html
.. _"Security in Debian" talk at DebConf 3: http://people.debian.org/~jfs/debconf3/security/security-discussion.pdf
.. _Debian Developers' Reference: http://www.debian.org/doc/developers-reference/
.. _DebConf 5: http://www.debconf.org/debconf5/
.. _established: http://lists.debian.org/debian-devel-announce/2005/06/msg00017.html
.. _debian-policy mailing list: http://lists.debian.org/debian-policy/
.. _Debian Bug Tracking System: http://www.debian.org/Bugs/
.. _announced our need for a new hosting site: http://lists.debian.org/debian-devel-announce/2005/06/msg00016.html
.. _above.net: http://above.net/
.. _appreciate it: http://www.debian.org/partners/
.. _previous report: http://people.debian.org/~branden/dpl/reports/2005-05-08.html
.. _Arch: http://arch.debian.org/
.. _Subversion repositories: http://svn.debian.org/
.. _Debian website: http://www.debian.org/
.. _debian-announce mailing list: http://lists.debian.org/debian-announce/
.. _aKademy 2005: http://conference2005.kde.org/
.. _Software in the Public Interest, Inc.: http://www.spi-inc.org/
.. _may be available: http://www.spi-inc.org/president/ar/
.. _FISL 6.0: http://fisl.softwarelivre.org/6.0/
.. _Gervase Markham's 14 June reply to Thijs Kinkhorst: http://lists.debian.org/debian-devel/2005/06/msg01182.html
.. _debian-devel mailing list: http://lists.debian.org/debian-devel/
.. _debian-legal mailing list: http://lists.debian.org/debian-legal/
.. vim:set ai et sts=4 sw=4 tw=72:
--
G. Branden Robinson
Debian Project Leader
leader@debian.org
http://people.debian.org/~branden/
Attachment:
signature.asc
Description: Digital signature