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

Platform for DPL election



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: pgpxXAR8ehuZT.pgp
Description: PGP signature


Reply to: