Hi everybody,
the platforms of the candidates have been published on the web :
http://www.debian.org/vote/2002/vote_0001
You'll find mine here :
http://www.debian.org/vote/2002/platforms/raphael
Here's a "lynx -dump" transcription for those who don't want to launch
their web browser. :-)
Raphaël Hertzog's platform for Debian Project Leader -- 2002
_________________________________________________________________
Presentation
My name is Raphaël Hertzog. I'm known as buxy on IRC. I'm a 23 year
old french student. The school where I study is called "[1]INSA de
Lyon" and I'm part of the [2]computer science department. I'll have my
engineer degree this summer after which I'll be looking for a job
related to free software (which hopefully will leave me much time for
Debian work).
History within Debian
My first contact with Linux was with Debian 1.3. It dates back to
1997. I first tried Debian because someone told me it had perl
installed by default and because I had discovered perl on Windows a
few months before and had thought that it was really cool. However I
quickly erased my Debian partition in order to try other distributions
(RedHat mainly). I came back to Debian a few months later for two main
reasons: it was used by the most competent people I knew within my
LUG, and I understood that it was the only distribution where I could
actually help and get involved.
In 1998, I joined Debian as a developer and started with a single
package called "[3]sympa". It wasn't even DFSG free (it had a clause
against commercial use) however the license has been corrected after
discussion with the upstream authors.
I quickly got interested by the Debian Quality Assurance work which
was still managed by Vincent Renardias. He initiated me to it. I
started to look for packages that I could work on with my perl skills,
and I found [4]dpkg-ftp (the ftp method of dselect). I took it over
since it was in a really bad shape and fixed all known bugs including
the wishlist ones.
In 1999, the debian-cd team had a problem because the script was not
really designed to manage multiple CDs and slink was the first Debian
version which needed more than a single CD. That's why I wrote YACS
(Yet Another Cd Script) (however I used parts of the slink_cd code
from Steve McIntyre) which became the official debian-cd for the
potato release. It featured a better design able to handle efficiently
multiple CDs and custom CDs (you can easily customize the content of
the CDs). I'm still the maintainer of debian-cd.
Also in 1999, we had big troubles with the new maintainer team. It
closed the doors for various reasons. I didn't agree with that
decision. That's why I launched the [5]sponsorship mechanism. The
principle is simple: each prospective maintainer has to find an
official Debian developer who will check his work and who will upload
his package into Debian. Of course, the Debian developer shares his
remarks about the package with the prospective maintainer so that he
can learn from it. And because of that the sponsorship system survived
even after the reopening of the new maintainer door. It appeared to be
a great tool to train the future developers and to make sure that they
share our principles (Social Contract, DFSG).
Still in 1999 (I didn't remember that I did so many things in the same
year ! :-)), I helped Darren Stalder to make perl-5.005 ready and I
managed the whole perl migration (all binary modules had to be
recompiled, I contacted everyone who was concerned and I NMUed
packages which had not been updated in time). At the same time I wrote
the first version of the [6]perl policy.
After that, I worked to resurrect Debian QA. I launched
[7]qa.debian.org (it still exists but the content has been completely
updated since then by the good work of several other QA workers like
Josip Rodin and Martin Michlmayr) and I created the QA committee. The
committee doesn't exist anymore because it didn't work. It was a try
to "organize" QA with a team deciding what has to be done and with
workers who do the real work. My interpretation of this failure is
that it was too centralized for Debian and that it didn't match
Debian's way of doing, and thus it failed.
Nowadays, I'm convinced that to keep up with the tremendous work and
to keep its high quality, Debian has to adapt itself to prevent
problems (packages badly maintained, packages forgotten and not
orphaned, ...) from happening. That's why I launched the [8]Package
Tracking System with the help from Anthony Towns. The main idea behind
the PTS is that we should have more people taking care of each
package. Taking care can mean several things from helping the
maintainer (for another developer) to just watching that the package
is well maintained (for an advanced user that cares about that
particular package).
And during all the time, I followed many mailing lists and
participated in dozens of discussions (and flames, even if I tend to
skip them since you usually just loose time with them). I also
sponsored many future maintainers and participated in several bug
squashing parties. And of course, I did my usual maintainer work: I'm
maintaining 5 perl modules, dpkg-ftp, debian-cd and logidee-tools.
With all this experience I believe to be quite familiar with Debian
and its way of working. I have been in contact with many people
involved in all the key aspects concerning Debian (boot-floppies,
ftpmasters, release manager, BTS maintainers, security team, QA team,
debian-www team, debian-admin, porters and buildd maintainers ...).
The role of the leader
In my opinion, the main tasks of the leader are "organization" and
"communication".
The organization part concerns the inner working of Debian, he has to
make sure that the Debian's infrastructure is adapted for the Debian
work. If necessary, he should initiate projects to resolve the
problems. If you want to know what kind of "infrastructure" I'm
speaking about, take a look at my program below.
The communication part can be split in two categories: internal and
external. The leader has to be in contact with as many people as
possible in Debian and has to make sure that everyone is going in the
same direction. The leader also represents Debian in the "outside"
world, he responds to interviews, participates in shows and so on.
However it's not always possible to go everywhere you're invited and
thus I'm thinking about the possibility to appoint local
representatives of the leader (volunteers of course).
In short, the leader has to make sure the Debian work can be done in
good conditions and that everyone involved is having fun and can be
proud of what he did ...
Projects for Debian
My program contains so many items that I can't guarantee that they
will all be completed. However I'll do everything possible to see as
many of them through the end. Each project will be assigned a
responsible person (candidates are encouraged to contact me) who
should keep me informed of their progress. I'll periodically publish
messages explaining where each of the projects are and what their
status is.
Here's the list of all the projects I'd like to manage during the next
year. They are classified in 2 categories:
* 1. Organisation
+ 1.1 Sourceforge for Debian developers
+ 1.2 Ping the maintainers
+ 1.3 Recruit people for adopting packages
+ 1.4 Localization infrastructure
+ 1.5 A second security team
+ 1.6 Don't mix stable and unstable packages
+ 1.7 More frequent freezes/releases
+ 1.8 Extension for the Package Tracking System
+ 1.9 CVS repository for debian directories
* 2. Communication (internal and external)
+ 2.1 Debian Best Packaging Practices
+ 2.2 Updated Debian Developer's Reference
+ 2.3 Promote the idea of collaborative maintenance and
backup maintainers
+ 2.4 Create more debian-devel-<language> lists
+ 2.5 Advertise Debian's offers and needs to the free software
actors
+ 2.6 Get in touch with upstream developers
+ 2.7 Promote Debian in business
+ 2.8 Acknowledge and cooperate with distributions based on
Debian
______________________________________________________________________
1. Organisation
1.1 Sourceforge for Debian developers
Creating a sourceforge.debian.org to let Debian developers host their
own free software projects is a good idea for several reasons :
* The traditional mailing list and CVS services provided by Debian
are only used for projects of general interest to Debian.
Developers can't request a mailing list or CVS repository for a
project not directly related to Debian (in particular if it
concerns only a few people). Here the sourceforge tool would let
each developer have a mailing list or CVS repository (along with
all the sourceforge services) for his projects;
* All the projects hosted on sourceforge.debian.org would be
identified as coming from the Debian community and it would make
us more visible as an active part of the free software community;
* Sourceforge is a good way to launch projects that we want to
spread further than Debian alone. I'll take the menu system as an
example, it has been developed by Debian originally, but it's not
really Debian specific (Mandrake is reusing it) but if it would
have been somewhere where non-Debian people can easily help, maybe
it would be used by even more people now;
* SourceForge can be a great tool to let non developers work on
certain parts of Debian. Think about the documentation and the
numerous translators.
Of course, the projects hosted on sourceforge.debian.org would not
need to be Debian specific. The only criteria would be that the
project must be requested by a Debian developer.
____________________________________________________
As you may know, I have been part of the Debian-QA effort for quite
some time and as such, I'd like to make it more popular and more
effective. While I have no miraculous solution (we can advertise it a
bit more, but that's part of the "communication" projects), I have
some new tasks for it:
1.2 Ping the maintainers
This idea always comes up again and again, but nobody really did it.
Martin Michlmayr started something for tracking MIA maintainers but he
doesn't contact everybody, just people who have been detected as MIA
by someone else (who noticed a huge bug list without any answer and so
on). It's time that we do it effectively by contacting all maintainers
who either have packages in bad shape or have disappeared (according
to echelon's information):
* we can detect MIA maintainers and orphan the corresponding
packages ;
* we can inform the maintainers of the state of their packages and
make them realize that they should find some help or orphan some
packages if they are in bad shape;
* maintainers who forget they were Debian developers may wish to
retire (I'd prefer them to get back to work, but if they don't
plan to come back to Debian, then they should retire so that we
can reduce the risks of their key getting hacked);
1.3 Recruit people for adopting packages
As you know, we have a growing number of orphaned packages and many
more packages that aren't orphaned but really should be (since they
are not well maintained). We have two solutions with orphaned
packages; either we remove them or we find a new maintainer. Removing
packages is already done from time to time by the QA team. But nobody
is really trying to find new maintainers. Making the list of orphaned
package available on the web is not enough (it's a pain to read
through it anyway).
We have to build a team which will take contacts with the (past and
current) maintainer(s), past contributors that can be found on the
BTS, upstream authors and mailing lists specialized on that package.
The goal is to find a new maintainer and several motivated persons
that would subscribe to the PTS to help clean (and maintain) the
package. If we can't find an actual Debian developer, the team would
have to find a sponsor until one of the interested people become an
official developer.
Maintainers could also request the help of this team to find "backup
maintainers" and/or contributors to help in the management of their
package.
All this work can be coordinated through a new "virtual package" in
the BTS (much like "wnpp", I have no idea for a name however).
____________________________________________________
Being French, i'm quite aware of localisation (and
internationalisation) issues. We still have much work left until we
reach full internationalisation. I believe that we need a better
infrastructure to coordinate between translators, proofreaders and
developers. The DDTP of Michael Bramer is a first step in this
direction even if it generated lots of flames on debian-devel...
1.4 Localization infrastructure
I don't have a precise idea yet on how it should be setup. However we
know the problems we have to manage:
* We have to translate at least (and keep up to date) the debconf
templates, the packages' descriptions and the Debian specific
program (messages and documentation). Going further would imply
coordination with people who are working on free software outside
of Debian; it would be interesting, but we should first focus on
what is directly Debian related.
* We need an effective way to distribute the work of translating.
For that the DDTP is a great step I think.
* We have to make sure that translations which are sent to the BTS
actually get included. Too many of them are still lying in the BTS
even if it's fairly easy to include them.
You can also look at [29]Debian translation statistics to learn more
about the localisation process and to see the kind of information that
the new infrastructure should provide (in real time).
____________________________________________________
After years of good reports, Debian recently had some bad publicity
about how it managed the security alerts. I'd like to have some
improvements.
1.5 A second security team
We can create a second security team which would have access to the
same information than the main one and which would have access to the
same tools (rbuilder, ...). The main goal of this second team would be
to provide updated packages for the non-stable distributions. They can
also punctually help the main team by providing packages ready that
just have have to be checked (by the main team).
This second team actually coordinates with the maintainer to get a fix
quickly into unstable. They also provide a package for "testing" (or
any other distribution we may introduce...) by backporting the patch
if necessary. This fixed package may be directly put in testing or it
may simply be provided on security.debian.org/testing until a fixed
package has gotten its way into testing).
This second team does more or less [30]already exist, but it hasn't
been very effective yet. It needs to be extended (two people isn't
enough) and it needs to work on setting up the required infrastructure
(we don't yet have rbuilders for all the architectures).
____________________________________________________
You all know that we have serious issues with release management.
Anthony Towns is not to blame, he has done a great job so far, but we
need to go a step further. I have some proposals but they all need to
be discussed/amended. However it's not yet time to discuss them...
it's just to let you know that I plan to work on improving the release
management because the current situation is not acceptable in the long
run. This is all stuff for woody+1 of course, Anthony will continue to
manage woody's release and I'll support him as much as needed !
1.6 Don't mix stable and unstable packages
We have several problems with the current situation:
* testing is derived from unstable which consistenly gets new
versions of all packages (and new bugs at the same time);
* when we must provide an updated package for testing, we have to go
through unstable again. It means that the package may be
recompiled against a newer version of a library (which was not yet
available when the previous version of the package had been
uploaded) which may hold it within unstable (because that library
may have problems or other conflicts);
* when we are working on unstable packages we can't hold them in
unstable without filing a release critical bug on that purpose.
Think about GNOME 2 prerelease packages. They should never appear
in "testing" which is going to be our next "stable". The same
applies for XFree 4.2, Branden is not going to upload it to
unstable because that would mean that he can't provide updated
version of XFree 4.1 for testing ...
That's why I think that we need to have completely separate
distribution for the next stable in preparation and unstable. It's up
to the maintainer to decide when his package is ready to be included
in the distribution in preparation.
For the rest of my explanation, I'll call "working" the distribution
in preparation to which the maintainer decides to upload packages that
he believes to be mostly ready to be included in a "stable"
distribution.
People still work in unstable, but when the package is ready in
unstable, it is uploaded to working and not before ! Any package
uploaded to working is compiled against working.
That would let (for example) Branden upload xfree 4.2.0 into unstable
while still finalizing xfree 4.1 into working. Or, Gnome 2.0 can
easily be prepared in unstable and keep gnome 1.4 in "working" without
having to worry. Once a package (or a set of packages) is ready in
unstable, we may have a script pushing it into working and all
autobuilders (including the i386 one) will pick it and build it. That
way we may prevent some unnecessary source uploads which may introduce
bugs.
One of the consequences is that we should have autobuilders building
for "working" as well as for "unstable". That means we'll need more
autobuilders and more build chroots ... but it's a required step to
ease the release manager work: each maintainer decides if his packages
are suitable for stable. Once uploaded to working, the release manager
of course still has the possibility to control what he accepts.
And what about testing ? Well, we essentially keep it like it is.
Because it's great for some of our advanced users and it's a good way
to see if a package is a good candidate for "working" or not. And we
introduce "releasable" which consists of the result of the "testing
scripts" run against "working". "releasable" would be a consistent
distribution based on working packages. That is, it shouldn't be far
from being ready to release ...
A schema explaining release management is available:
http://people.debian.org/~hertzog/release-management.png
1.7 Freeze standard ("Debian core packages") regularly
Since the "working" distribution is only made of packages considered
as good by their maintainer, the base/standard system contained in
"working" should always be mostly ready and can be frozen regularly
(every 8 months) without requiring more than a few weeks of work. At
this moment, we have a period of one or two months, after which the
new stable distribution will be made (whatever happens ... packages
not ready at this time will simply be dropped).
This completely ignores boot-floppies, because I assume that they
should always be ready (if the new version is not ready, then the old
one should still be usable).
____________________________________________________
Last but not least, we have to go further for collaborative
maintenance of packages. I have two ideas in mind:
1.8 Extension for the Package Tracking System (PTS)
I implemented (with the help of Anthony Towns for the BTS
modifications) the Package Tracking System. But it could be extended
with a web interface ; each source package would have its own web page
(with an URL like http://activity.debian.org/<sourcepackage>). This
page would aim to be a portal for the source package. It would include
many links (to the BTS, to the lintian pages, to packages.debian.org)
and some more information (like the information provided by madison on
auric). It would also have a news like system where people can add
news simply by mailing <sourcepackage>@activity.debian.org, which
would be directly available on the web. Here's the kind of news which
could be interesting:
* New beta packages available for tests
* Expect final version of the package for 2002-02-15 (to allow the
translators to update their translations, for example)
* Packaging is in the process of being redone
* Version X.Y-Z is screwed, how to fix
* NMU being worked on by Henri Dupont
* Maintainer on vacation until 2002-02-12 (if the maintainer wants
to publish this information ... it wouldn't be required, of
course)
* New upstream source available, packaging plans
* Bug squashing party on this package next week
The maintainer may also add some static information to that page, like
how he'd like the NMUs to be done, or what other useful resources are
available for that package (upstream bug tracking system, irc
channels, mailing lists...).
This extension should let many more people rapidly jump in and know
the essential information about the package. QA workers can check what
is going on with the package, and at freeze time it can be an
invaluable tool to indicate that a QA worker is going to take care of
this package.
1.9 CVS repository for debian directories
Another natural step when more people are going to work on the same
package is to put the debian/* files under CVS control. We need to
provide some disk space on our CVS server for that purpose. We need a
tool to automatically create such a repository (i.e. each maintainer
could require a CVS repository for its own package by calling a
program on the good server). The integration with the packaging tools
should be a bit studied and helper tools should be provided (to
update, commit, manage branches (stable/unstable) and tag files when a
package is uploaded and so on). cvs-buildpackage might be used for
that purpose.
Suppose that all Debian developers have write access on all those cvs
repositories, the advantages are numerous and the main maintainer can
still have some control:
* The translation team could directly commit the translations
without requiring work from the maintainer;
* NMUers would no more need to send a patch to the BTS. The patch is
directly applied to CVS; the maintainer can revert it or keep it;
* It's far easier for the maintainer to have co-maintainers, he
doesn't have to "centralize" patches. He just needs to update its
local repository from time to time;
* We can easily maintain two version of the packages (stable and
unstable for example) using CVS branches;
* The maintainer(s) can have a mail for each commit with the patch
and the log attached. With such a system he can see who did what,
and detect potential mistakes.
Of course, this service would be optional, maintainers wouldn't be
forced to use it.
______________________________________________________________________
2. Communication
First of all, our internal communication needs to be improved. Some
useful things are only known by the maintainers who follow either
debian-devel or #debian-devel. That's not really acceptable. If there
are things that are of interest to all developers we should document
them (and announce them on debian-devel-announce).
2.1 Debian Best Packaging Practices
The first time I heard of this was on IRC; it was an idea from Matthew
Wilcox. Since I really liked the principle of this idea, I have
included it in my program.
The DBPP is going to be a manual referencing all the best solutions
available for maintaining a package: use DBS if you have to manage
several upstream patches, use debconf for user interaction, how to
handle config files that you want to auto-generate and so on. We have
accumulated years of experience that we must capitalize upon.
2.2 Updated Debian Developer's Reference
The Debian Developers' Reference is already an invaluable
documentation for the maintainers, but we have to keep it up to date
with respect to the resources available (document the PTS for example,
and all other projects completed and mentioned in the first part of my
program).
Furthermore it should also give a list of things that a developer can
(or should) do apart from maintaining his own package(s) (i.e. quality
assurance, sponsorship, application management, working on the
installer, participating in bug squashing parties, ...).
It could also benefit from more translations.
2.3 Promote the idea of collaborative maintenance and backup maintainers
The idea of collaborative maintenance is not very widely spread within
Debian. Only a few packages are managed by a full team. This has to
change. We have to explain how useful it is to be several maintainers
for each package. We have to document all the resources available for
the co-maintenance (PTS, Uploaders field, CVS, ...).
For smaller packages, where several maintainers are not really needed,
it's still useful to have "backup maintainers", who can help
punctually like when the maintainer is on vacation (or when he's
really busy). And since they'd follow the package, they'll prevent the
package from being forgotten in the limbo ... :-)
2.4 Create more debian-devel-<language> lists
I created debian-devel-french a few months ago and it would be
interesting to have more dedicated list like this one (we also already
have debian-devel-spanish) for each major language (I have no criteria
for defining "major language"). Such lists are useful, because
maintainers who don't follow debian-devel may follow the local
counterpart which usually has much less traffic. If good ideas come up
on the local list, they'll always be forwarded by a maintainer who's
following both lists. The contrary happens too; some things discussed
on debian-devel also get discussed on the local list. The list also
serves the purpose of debian-mentors but in one's native tongue (it's
much friendlier and much easier to find a sponsor in this context).
____________________________________________________
Despite Debian's openness, we aren't much trying to communicate with
people outside of Debian; we just let them find themselves on the
website what they want to know. We should be more active, we must try
to tell them what we want them to know.
2.5 A message adapted for each population
We certainly have many things to say to everyone. However we have to
adapt our message for each population. Exactly what we are going to
tell them is what Debian can offer to them and what Debian needs that
they may provide. Here's the list of people concerned and examples of
messages (the list may be discussed and extended of course):
* An average user
+ How to get Debian (CD vendors) and its derivative
distributions
+ Where he can find Debian support (community or commercial)
+ How to donate (money or hardware) to Debian
* A contributor (an advanced user)
+ How to track Debian's development (testing, mailing lists,
PTS, ...)
+ How to report bugs and how to follow them
+ How to help without being developer (translations, patches,
feedback, quality assurance in general...)
+ How to get a developer for further involvement
* A linux user group
+ Where to find stuff for install-parties, demonstrations,
expositions (posters, documentation, logos, cool background
images, explanation of Debian's advantages, ...)
+ Support beginners who discover Debian through their local
mailing lists
+ Offer facilities for Debian users (local mirror, sell Debian
CDs, ...)
* A free software author
+ How to ask that someone packages his software (RFP in wnpp)
+ How to follow the package within Debian (PTS, BTS)
+ How to help the maintainer and what cooperation is expected
from him
+ How to get a developer to maintain his package himself
* A commercial company
+ How to get commercial support for Debian
+ Acknowledge publicly your Debian's use ("Debian powered")
+ Donate to Debian (money or hardware)
+ Hire Debian developers for your internal support and let them
work part-time on Debian
2.6 Get in touch with upstream developers
I have the feeling that too few maintainers have real contacts with
the upstream authors. This should change, we should have better
contact with them and we should even try to recruit the upstream
developers who are already using Debian. We should inform them of how
they can help (without going through the hassle of getting Debian's
developer) by subscribing to their packages with the Package Tracking
System and by taking into account the bug reports that are forwarded.
The better the upstream authors know Debian, the better the
cooperation will be. That's why I'd like us to write a kind of "open
letter to the free software authors" (which could be inspired by the
page described in the previous point) that each maintainer should
forward to the upstream developers of his packages.
2.7 Promote Debian in the business
While Debian isn't a commercial distribution, it is meant to be used
everywhere including in corporate and commercial environment. Debian's
development in that area should be encouraged because the more
companies know about Debian, the more donations we can have, and the
more developers can get paid to work on Debian.
The simplest thing that we can do for this is to give the possibility
to Debian's users to publish where Debian has been used and how it has
been used in the corporate world (Mandrake did something like that
with [31]MandrakeBizCases).
That website could also give links to the pages which might interest
companies looking into corporate use of Debian. I'm thinking about the
[32]consultants pages or the list of vendors who sell [33]Debian
pre-installed hardware.
2.8 Acknowledge and cooperate with distributions based on Debian
All the distributions that are based on Debian help Debian by
spreading the .deb package format and by providing other (and
sometimes simpler) ways to install Debian. We must be proud of them
because they always reuse many things of Debian, they don't fork for
the sake of it, they add some value to Debian. And most of the time,
they contribute it back.
That's why I think that we should have a web page acknowledging their
existence (something [34]already exists but it needs to be improved
and to be more visible). I also think that we should reinforce
relationships with them, just to make sure that the most interesting
items are contributed back.
____________________________________________________
That's enough I guess, a year is only 365 days. :-) If you are
interested to work on any of those projects, feel free to let me know.
Of course, there are many other projects which are worth doing
(simpler installer based on debian-installer or the recently announced
PGI, hardware detection in standard, ...) and I hope that we'll
achieve them but they're not really under the DPL's responsibility.
Conclusion
Thank you for your attention. This upcoming year is going to be very
exciting and very hard for the next leader; he will need your support.
That's why I hope you will all vote in the forthcoming election. Until
then, have fun !
_________________________________________________________________
Raphaël Hertzog.
References
1. http://www.insa-lyon.fr/
2. http://www.if.insa-lyon.fr/if/
3. http://packages.debian.org/sympa
4. http://packages.debian.org/dpkg-ftp
5. http://lists.debian.org/debian-devel/1999/debian-devel-199907/msg01530.html
6. http://www.debian.org/doc/packaging-manuals/perl-policy/
7. http://qa.debian.org/
8. http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200201/msg00011.html
29. http://www.debian.org/intl/l10n/
30. http://lists.debian.org/debian-security/2001/debian-security-200109/msg00225.html
31. http://www.mandrakebizcases.com/
32. http://www.debian.org/consultants/
33. http://www.debian.org/distrib/pre-installed
34. http://www.debian.org/misc/related_links
35. mailto:hertzog@debian.org
--
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Formation Linux et logiciel libre : http://www.logidee.com
Attachment:
pgppufv3mTtw9.pgp
Description: PGP signature