Differences between revisions 1 and 15 (spanning 14 versions)
Revision 1 as of 2005-12-15 10:40:35
Size: 4423
Comment:
Revision 15 as of 2013-08-23 13:06:30
Size: 5899
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
This proposal is a very far-reaching proposal which started from the discussion about OrphanedPackages and which has been discussed IRL during the QA meeting (see [http://meetings-archive.debian.net/pub/debian-meetings/2005/qa-meeting-darmstadt/ the videos here]). #language en

= Working with CollabMaint =

For information about working with packages and repositories that are part of the Collaborative Maintenance project (CollabMaint) hosted at Alioth [[https://wiki.debian.org/Alioth/CollabMaintImport|visit the CollabMaintImport wiki page]]

= Collaborative Maintenance Proposal =

This proposal is a very far-reaching proposal which started from the discussion about OrphanedPackages and which has been discussed IRL during the QA meeting (see [[http://meetings-archive.debian.net/pub/debian-meetings/2005/qa-meeting-darmstadt/|the videos here]]). Everybody interested by this proposal is welcome to join the [[http://lists.alioth.debian.org/mailman/listinfo/collab-maint-devel|collab-maint-devel]] mailing list.

Related pages:
 * [[/Design|Suggested design for the infrastructure]]
 * [[/Status|Some news about the actual status of this proposal]]
Line 16: Line 28:
 * Make it possible fot external contributors to maintain packages even if they don't want to become Debian developers  * Make it possible for external contributors to maintain packages even if they don't want to become Debian developers
Line 21: Line 33:
Collaborative maintenance means using a Version Control System. Subversion beeing the most popular choice nowadays, we'll use this one as the basis of this proposal. Collaborative maintenance means using a Version Control System (VCS). Subversion being the most popular choice nowadays, we'll use this one as the basis of this proposal. However the infrastructure must be designed in a VCS-agnostic manner: it must be possible to write modules to add support of other VCS.
Line 54: Line 66:
== Content generated automatically ==  == Content generated automatically ==
Line 57: Line 69:
 * Output of lintian / linda ?  * Output of lintian ?
Line 67: Line 79:
For beginners who are not ready to use SVN yet, we may have a Dak install so that people can upload sources packages which would then directly get injected in the repository (idea from [NeilMcGovern] reformulated by RaphaelHertzog).
Line 70: Line 84:
 * Ubuntu is currently working on a tool called [http://revu.tauware.de/cgi-bin/trac.cgi REVU] which helps reviewing the packages from external contributors.
 * [http://mentors.debian.net/ mentors.debian.net]
 * [http://sponsors.debian.net/ sponsors.debian.net] (Contact: neilm@debian.org)
 * Ubuntu is currently working on a tool called [[http://revu.tauware.de/cgi-bin/trac.cgi|REVU]] which helps reviewing the packages from external contributors. See the [[https://wiki.ubuntu.com/REVU2Spec|specifications]] in particular for good ideas.
 * [[https://wiki.ubuntu.com/MultiDistroTools|MultiDistroTools]] is a set of tools to help the MOTU in their work (review of packages, comparison with Debian, etc.)
 * [[http://mentors.debian.net/|mentors.debian.net]] (Contact: support@mentors.debian.net / haas@debian.org)
 * [[http://sponsors.debian.net/|sponsors.debian.net]] (Contact: neilm@debian.org)

See also : [[Alioth/PackagingProject]]

----
CategoryPermalink
## this page is the home page of http://alioth.debian.org/projects/collab-maint/

Working with CollabMaint

For information about working with packages and repositories that are part of the Collaborative Maintenance project (?CollabMaint) hosted at Alioth visit the CollabMaintImport wiki page

Collaborative Maintenance Proposal

This proposal is a very far-reaching proposal which started from the discussion about OrphanedPackages and which has been discussed IRL during the QA meeting (see the videos here). Everybody interested by this proposal is welcome to join the collab-maint-devel mailing list.

Related pages:

Short summary

We want to setup a complete infrastructure for handling the maintenance of (sets of) Debian packages. This infrastructure is meant to be used in several cases which have different expectations about such an infrastructure. Namely :

  • Usual co-maintenance (like pkg-gnome.alioth.debian.org) with Debian developers and external contributors
  • Co-maintenance of orphaned packages by the Debian QA Group
  • Packages from future Debian developers who are currently in the NM process
  • Packages from future MOTU which are in the MOTU School
  • Packages created by Ubuntu's MOTUs which must be integrated in Debian (to avoid divergence)

Goals and expected benefits

  • Make it easier for external contributors to help in the maintenance of Debian packages
  • Make it easier for Debian developers to sponsor and mentor volunteers
  • Make it possible for external contributors to maintain packages even if they don't want to become Debian developers
    • (this is only possible if the sponsoring process works well and that's why we need to improve our tools to make that easier)

How do we do that ?

Collaborative maintenance means using a Version Control System (VCS). Subversion being the most popular choice nowadays, we'll use this one as the basis of this proposal. However the infrastructure must be designed in a VCS-agnostic manner: it must be possible to write modules to add support of other VCS.

So the main part of the infrastructure is a subversion repository. Packages are handled like usual with svn-buildpackage in their own directory. Up to now, this is nothing new as many people already do it. We need to add meta-information in the repository and provide several services to ease the work of everyone.

What needs to be done

Meta-information to integrate in the infrastructure

  • A "maintenance-status" field describing each package :
    • orphaned: packages without regular maintainer
    • mentored: packages from someone who wants to become DD/MOTU (may also be a group of future DD/MOTU)
    • maintained: packages where a regular DD/MOTU is in the maintenance team
    • lowmaint: packages maintained by external contributors with no regular DD/MOTU in the team
  • An "upload-status" field (associated to the current version) :
    • need-review / need-upload
    • ready-for-upload / needs-more-work
    • uploaded

Access control layer

Since we want to open the access to many external contributors, we should be able to restrict their access to the packages that they are interested in. Of course the ACL (Access Control List) must be maintained by a group of trusted developers.

Web page

A (dynamic) web page must be created which describes the characteristics of all packages maintained in the repository :

  • Does the package exist in Debian ? (in Ubuntu ?)
  • Is the version in the repo newer than the version in unstable/experimental ?
  • Does the maintainer look for a "sponsor" ? (~ is the package ready to be uploaded ?)
  • Usual links :
    • Package Tracking System
    • Bugs
  • Links to any "generated content" (see below)

Content generated automatically

  • Diff between last version uploaded and actual version in repo
  • Output of lintian ?
  • Output of pbuilder run ? piuparts ?
  • Generate an aptable source repository (possibility to download the last sources without using svn)

Automatic integration with Debian infrastructure

For example, it should be possible to configure the infrastructure so that each SVN commits sends a mail with the diff to the Package Tracking System.

Also, the system should follow uploads made to unstable/experimental and check that they come from the repository. If not it should reintegrate it in the repo. It should also inform the maintainers about this (unfortunate) event.

For beginners who are not ready to use SVN yet, we may have a Dak install so that people can upload sources packages which would then directly get injected in the repository (idea from [NeilMcGovern] reformulated by RaphaelHertzog).

Links

Here are some other projects which should be contacted and which are working in the same direction :

See also : ?Alioth/PackagingProject


CategoryPermalink