Platforms for Raphaël Hertzog

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 "INSA de Lyon" and I'm part of the 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 (Red Hat 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 "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 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 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 perl policy.

After that, I worked to resurrect Debian QA. I launched 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 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 squash 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.

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

Creating a sourceforge.debian.org to let Debian developers host their own free software projects is a good idea for several reasons :

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):

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: You can also look at 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 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 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:

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 ...

Release management

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 a 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:

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:

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):

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 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 consultants pages or the list of vendors who sell 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 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.

Rebuttal

About Bdale's platform

I don't have much to say about Bdale's platform since I agree with most of what he said. I can only recognize his experience within Debian and the invaluable work he has already done. I share his vision of Debian; however I think that his platform lacks concrete propositions. It's perfectly understandable because you can know where you want to go without knowing how you'll go. If he's elected, I hope he will see that some of the projects that I propose are going in the direction where he wants to lead us and that as such he will promote them enough to make them happen.

He mentioned that he would attend many events due to his new job in the Linux Labs at HP; as such I'd be more than happy if he wanted to be one of the DPL representatives.

Bdale would certainly*1 get my support for any concrete project he would like to launch related to one of the items he mentioned in his platform ("Quality", "Release predictability", "User First Impression", "Infrastructure", "Security", "Linux Standard Base").

[*1] Well, I can't guarantee it since I don't know what those projects would be... but I'm saying that because I know that Bdale is very reasonable and has always done a good job. Take that as a proof of trust.

About Branden's platform

Branden is *someone* within Debian, nobody is indifferent to him. People may remember how we gently flamed each other. I'm familiar with Branden's way of doing; I wish everyone would be, at least they wouldn't feel hurt when they discuss with him. :-) I have to admit that I appreciate Branden's effort to be more comprehensive and to flame only as a last resort. Keep up the effort ! ;-)

He has always done a great job with XFree86 and he has proven his ability to manage other non-technical issues (SPI treasurer comes to my mind first but I also think of the various propositions he made to change the constitution or the Debian Machine Usage Policy, and also several things he managed on debian-private that I can't quote here :-)).

Here are my comments about his platform. While I understand the motivation of clearly defining the role of DPL delegates I do think that it's not useful for Debian and that it's just the kind of bureaucracy that we don't need. Teams are well known, people who are part of them too, and the way to get in touch with them is documented. We don't need more than that. The "keeping the developer base active" and "Debian's representation at function" are two items of his platform which I fully share. The items "Debian's relationship with SPI" and "Reactivation of the Debian technical committee" are two projects that I'm not much interested in but that are valuable and worth pursuing and as such I'd be happy to let Branden manage them as a DPL delegate.

About my platform

At this point, I do not want to change anything in my platform (except a few spelling errors :-)); I believe that the required clarifications have already been given on debian-vote.

The biggest concern has been about "SourceForge". We won't call it "SourceForge" to make it obvious that it's not affiliated to VA Research. But we'll use the sourceforge code since it's packaged and it does work. However if someone comes up with another working free software with as many features, we'll consider it of course.