Debian-news is about one simple thing - news about Debian GNU/Linux and the top free distributions based on Debian GNU/Linux.


Guidelines for packaging projects on Alioth

Raphael Herzog have announced guidelines for packaging projects on the Alioth project.

as we have more and more packaging projects on Alioth I want to provide
some guidelines for people running those projects (and for people who
might want to start a new one).

Executive summary:
* Collaborative maintenance of a single package doesn't require a
dedicated Alioth project, you can use the “collab-maint” project
which exists for that purpose and which provides smooth integration
with the Package Tracking System.
* If a maintainer wants to maintain his package in a public SVN
repository, he can also use the “collab-maint” repository (even if
there are no co-maintainers).
* All existing packaging projects should use svnmailer to send SVN diffs
to the Package Tracking System. A sample configuration file is provided
and I can help if you have troubles installing it.

Detailed information are available in this wiki page, please check it out:

Here's a slightly edited lynx -dump of this page for your convenience:

1. Collaborative maintenance of a single package

If you maintain collaboratively only a single package, you probably
don't need a full Alioth project with mailing list and everything. You
should use the subversion repository[24] of the collab-maint
project[25]. Thanks to ACL, all Debian developers have write access on
this repository. SVN commit notifications are automatically sent to the
Package Tracking System (you need to subscribe in “advanced mode” on
the web interface and to activate the “cvs” keyword, check the
PTS documentation[26]).

To integrate your package in the repository, use svn-inject (with
option -o to avoid storing upstream sources) with the following URL:
svn+ssh:// If the package is
maintained by external contributors, it should be put in the ext-maint
directory instead of deb-maint (it can easily be moved later if

If you need to grant access to external contributors, please ask
[27]RaphaelHertzog to add a specific “xxx-guest” user to the
collab-maint Alioth project.

1.1. Discussions between co-maintainers

Since you don't have a dedicated mailing list for the maintenance, you
have 2 solutions:
* use extensively the BTS. You can submit wishlist bugs on your
package to keep track of improvements that you want to do. Since
co-maintainers are subscribed to the PTS, they will receive
everything and the discussion can happen via the BTS itself. The
BTS is the TODO list for your package and every contributor can
follow your plans (and offer help and patches!).
* create a dedicated email alias on a debian account. Putting emails
of all co-maintainers in a ~/.forward- file on will create the -
email alias.

1.2. Non-collaborative maintenance

If a maintainer wants to maintain his package within subversion, he
can use the collab-maint repository even if the package is not (yet)
collaboratively maintained. This is always useful since contributors
are more likely to propose patch if they can be sure that the work has
not yet been done. That's why the use of the SVN repository should be
documented as a static news[28] in the PTS (check the result on
the debian-cd PTS[29] page for example).

2. Collaborative maintenance of a set of related packages

If you plan to maintain many related packages with the help of a team,
you can request a dedicated Alioth project. Its name should start with
“pkg-“. This gives you access to all the services associated to an
Alioth project (website, mailing lists, trackers, forums, etc.).

Examples of such projects are: [30]pkg-perl, [31]pkg-gnome, …

2.1. Configuring SVN to send commit notifications

It is very important that you install a SVN hook to send commit
notifications to the Package Tracking System since this is the
canonical way for many people to follow what's happening on a given
source package.

[32]Svnmailer is a python script that can be configured to
handle this complicated task (extract the package name from the
changeset and send out the diff to the right email) and it's available
on You can find a sample configuration file with full
comments (and a sample of a post-commit file for the hooks directory
of a subversion repository) in the [33]collab-maint SVN
repository: [34]post-commit and [35]svnmailer.conf

You may need to modify the for_paths variable if packages maintained
in the repository are somewhere else than in /packages/. If you have a
mailing list which should receive all commit notifications, you can
comment to_fake and use to_addr, listing there your mailing list for

Please never disclose publicly the
package_cvs _AT_ email address used to send the
commit notifications. That's why the default configuration above uses
bcc_addr instead of to_addr to effectively send the mail to
package_cvs@p.q.d.o while pretending to send to package@p.q.d.o.

Feel free to ask [36]RaphaelHertzog if you need more information on
this subject.

2.2. Setup a basic web site

Having an empty project web page doesn't look good. Please put some
useful information in
/org/ /htdocs, at the
very least some links to the subversion repository, to the web page
used to follow the status of all the packages maintained within the
project, etc.

Check for example [37]

2.3. Disable Alioth services which are not needed

An Alioth project provide many services like trackers, forums,
surveys, file download, etc. Most of those services are activated by
default. Please disable all that you don't use via the administration
web page.


– Raphaël Hertzog Premier livre français sur Debian GNU/Linux :

No Response to “Guidelines for packaging projects on Alioth” »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Debian-News is not related to the Debian Project.
All logos and trademarks on this site are property of their respective owners.