Differences between revisions 21 and 22
Revision 21 as of 2008-09-07 20:00:10
Size: 8120
Editor: FranklinPiat
Comment: CategoryPermalink
Revision 22 as of 2009-03-16 03:31:45
Size: 8154
Editor: anonymous
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
You may also want to check the other Alioth pages: ["Alioth"] and ["Alioth/FAQ"]. You may also want to check the other Alioth pages: [[Alioth]] and [[Alioth/FAQ]].
Line 9: Line 9:
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 one VCS ([http://svn.debian.org/wsvn/collab-maint/deb-maint/ subversion repository], [http://git.debian.org/ GIT repository], [http://bzr.debian.org/collab-maint/ bzr repository], ...) of the [http://alioth.debian.org/projects/collab-maint/ collab-maint project]. Thanks to ACL, all Debian developers have write access on those repositories. For 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 [http://www.debian.org/doc/manuals/developers-reference/ch-resources.en.html#s-pkg-tracking-system PTS documentation]). 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 one VCS ([[http://svn.debian.org/wsvn/collab-maint/deb-maint/|subversion repository]], [[http://git.debian.org/|GIT repository]], [[http://bzr.debian.org/collab-maint/|bzr repository]], ...) of the [[http://alioth.debian.org/projects/collab-maint/|collab-maint project]]. Thanks to ACL, all Debian developers have write access on those repositories. For 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 [[http://www.debian.org/doc/manuals/developers-reference/ch-resources.en.html#s-pkg-tracking-system|PTS documentation]]).
Line 12: Line 12:
It is also possible to import all your previous changes from an existing repository into the collab-maint repository, see ["Alioth/CollabMaintImport"]. It is also possible to import all your previous changes from an existing repository into the collab-maint repository, see [[Alioth/CollabMaintImport]].
Line 15: Line 15:
If you need to grant access to external contributors, please ask your contributor to [http://alioth.debian.org/account/register.php register an account] if he doesn't have one and request to become a member of collab-maint by going [https://alioth.debian.org/projects/collab-maint/ here] and selecting "request to join". If you need to grant access to external contributors, please ask your contributor to [[http://alioth.debian.org/account/register.php|register an account]] if he doesn't have one and request to become a member of collab-maint by going [[https://alioth.debian.org/projects/collab-maint/|here]] and selecting "request to join".
Line 25: Line 25:
If a maintainer wants to maintain his/her package within subversion, (s)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 through the [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=391023 Vcs-* field] in `debian/control` (and through that, the PTS) or alternatively [http://www.debian.org/doc/manuals/developers-reference/ch-resources.en.html#s-pts-web static news in the PTS] (check the result on the [http://packages.qa.debian.org/debian-cd debian-cd PTS page] for examples). If a maintainer wants to maintain his/her package within subversion, (s)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 through the [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=391023|Vcs-* field]] in `debian/control` (and through that, the PTS) or alternatively [[http://www.debian.org/doc/manuals/developers-reference/ch-resources.en.html#s-pts-web|static news in the PTS]] (check the result on the [[http://packages.qa.debian.org/debian-cd|debian-cd PTS page]] for examples).
Line 31: Line 31:
Examples of such projects are: [http://pkg-perl.alioth.debian.org/ pkg-perl], [http://alioth.debian.org/projects/pkg-gnome/ pkg-gnome], ... Examples of such projects are: [[http://pkg-perl.alioth.debian.org/|pkg-perl]], [[http://alioth.debian.org/projects/pkg-gnome/|pkg-gnome]], ...
Line 37: Line 37:
[http://opensource.perlig.de/svnmailer/ 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 svn.debian.org. 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 [http://svn.debian.org/wsvn/collab-maint/lib/trunk/hooks/ collab-maint SVN repository]: [http://svn.debian.org/wsvn/collab-maint/lib/trunk/hooks/post-commit?op=file&rev=0&sc=0 post-commit] and [http://svn.debian.org/wsvn/collab-maint/lib/trunk/hooks/svnmailer.conf?op=file&rev=0&sc=0 svnmailer.conf] [[http://opensource.perlig.de/svnmailer/|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 svn.debian.org. 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 [[http://svn.debian.org/wsvn/collab-maint/lib/trunk/hooks/|collab-maint SVN repository]]: [[http://svn.debian.org/wsvn/collab-maint/lib/trunk/hooks/post-commit?op=file&rev=0&sc=0|post-commit]] and [[http://svn.debian.org/wsvn/collab-maint/lib/trunk/hooks/svnmailer.conf?op=file&rev=0&sc=0|svnmailer.conf]]
Line 58: Line 58:
Whitelisting BTS mails is possible with the option "List of non-member addresses whose postings should be automatically accepted". You need to put "^.*@bugs.debian.org" in that field. You should also add "bts-link-upstream@lists.alioth.debian.org" to get notifications by [http://bts-link.alioth.debian.org/ bts-link] if upstream uses a bug tracking system that's supported by bts-link. Also consider adding "package@packages.debian.org" and "package@packages.qa.debian.org" where "package" is the source package name. In such case, also set "require_explicit_destination: No". Whitelisting BTS mails is possible with the option "List of non-member addresses whose postings should be automatically accepted". You need to put "^.*@bugs.debian.org" in that field. You should also add "bts-link-upstream@lists.alioth.debian.org" to get notifications by [[http://bts-link.alioth.debian.org/|bts-link]] if upstream uses a bug tracking system that's supported by bts-link. Also consider adding "package@packages.debian.org" and "package@packages.qa.debian.org" where "package" is the source package name. In such case, also set "require_explicit_destination: No".

This page contains guidelines to help you setup collaborative maintenance of packages on Alioth. You may also want to check the other Alioth pages: Alioth and ?Alioth/FAQ.

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 one VCS (subversion repository, GIT repository, bzr repository, ...) of the collab-maint project. Thanks to ACL, all Debian developers have write access on those repositories. For 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).

To integrate your package in the subversion repository, use svn-inject (with option -o to avoid storing upstream sources) with the following URL: svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/ It is also possible to import all your previous changes from an existing repository into the collab-maint repository, see ?Alioth/CollabMaintImport. 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 needed).

If you need to grant access to external contributors, please ask your contributor to register an account if he doesn't have one and request to become a member of collab-maint by going here and selecting "request to join".

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!).
  • use the alias <package>@packages.debian.org: the maintainer gets the mail directly and the co-maintainers get the mail through the PTS (if they are subscribed to the "contact" keyword)

1.2. Non-collaborative maintenance

If a maintainer wants to maintain his/her package within subversion, (s)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 through the Vcs-* field in debian/control (and through that, the PTS) or alternatively static news in the PTS (check the result on the debian-cd PTS page for examples).

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: pkg-perl, 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.

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 svn.debian.org. 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 collab-maint SVN repository: post-commit and 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 commits.

Please never disclose publicly the package_cvs _AT_ packages.qa.debian.org email address used to send the commit notification. That's why the default configuration above uses bcc_addr instead of to_addr to effectively send the mail to package_cvs@... while pretending to send to package@....

Feel free to ask on #alioth on IRC 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/alioth.debian.org/chroot/home/groups/<project>/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 http://pkg-perl.alioth.debian.org/.

2.3. Configure mailing lists appropriately

If you put a mailing list as Maintainer of a package, you must configure the list to accept mails from anyone otherwise people submitting bug reports and other legitimate mails will get notices indicating that their message is in the moderation queue.

For that, go to the mailman administrative page of the list and click on "Privacy options", "Sender filters" and there you have to change the option "Action to take for postings from non-members for which no explicit action is defined" to "Accept".

This configuration is perfectly acceptable as the anti-spam filters are quite effective. Whitelisting BTS mails is possible with the option "List of non-member addresses whose postings should be automatically accepted". You need to put "^.*@bugs.debian.org" in that field. You should also add "bts-link-upstream@lists.alioth.debian.org" to get notifications by bts-link if upstream uses a bug tracking system that's supported by bts-link. Also consider adding "package@packages.debian.org" and "package@packages.qa.debian.org" where "package" is the source package name. In such case, also set "require_explicit_destination: No".

We strongly encourage you to use the "open to everyone" policy as this is the standard for all lists on lists.debian.org. To do so, in addition to turn off moderation, you have to set "generic_nonmember_action" to "accept" in Privacy options... / Sender filters, set "require_explicit_destination" to "no" in Privacy options... / Recipient filters, and set the value of "max_message_size" at the bottom of the "General Options" to 0.

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


CategoryPermalink ?CategoryAlioth