Platforms for Raphaël Hertzog
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 ...
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
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:
- 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).
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...
- 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.
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.
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 !
- testing is derived from unstable which consistently 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 ...
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:
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:
- 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.
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.
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.
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.
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 ... :-)
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.
- 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
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.
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.
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.
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 !
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.