[Collab-maint-devel] Re: GoogleSOC2007 - Collaborative Maintenance System Proposal Draft 1

[Raphael Hertzog]

Hi,

On Tue, 13 Mar 2007, Pavel 'Blaze' Vinogradov wrote:
 
> Benefits to the Debian Community
> 
>    Created infrastructure make easier for external contributors to help in
> the maintenance of Debian packages. It automatize applying and testing
> patches from registered external contributor. And simplify work of Debian
> QA-group and package mentors of build and review packages. Also it can help
> in adaptation new packages for inclusion in Official Debian repository and
> involves more people in Debian development.
> 
> Deliverables
>    Deliverable 1
>        Analysis of current state of collaborative maintenance in Debian,
> Ubuntu and other distribution. Define rules for project inclusion  in
> system, external contributor registration and sponsored by DD package
> uploads in Official repository.

Starting with an analysis is a good idea, but you should really pick
various exemples of meaningful collaborative maintenance (pkg-perl
project, pkg-gnome project, manual sponsoring on debian-mentors, etc.)
and analyze their work habites. What tools do they use? what can be
improved? etc.

I don't think that you need to define "rules" for project inclusion.
The infrastructure should be created so that people can use it, but the
people will create the rules themselves (who can commit, who can upload,
etc).

>    Deliverable 2
>        Implement infrastructure interaction with official source-package
> repositories. Included fetching latest packages source into VCS, filled
> project metadata information in DB and synchronization with changes in
> repositories.

Fetching latest sources is a difficult task because the upstream sources
are often not in the repository...

>    Deliverable 3
>        Implement development environment based on VCS for collaborative
> maintenance.

What does that mean ? The VCS already exists and are hosted on Alioth.

>        Included external contributor registration and accepting. Interact
> between contributor and mentors. Store additional metadata about
> contributors and their work in DB.

I would love if all the authentication could rely on OpenID.
http://www.ouaza.com/wordpress/2007/03/06/alioth-and-openid/

Concerning the "interaction" between mentors and contributors, I like what
Ubuntu has does with REVU. You should probably take that as a basis or at
least as a model.

>    Deliverable 4
>        Implement autobuild for packages maintain in VCS, lintian/linda
> check, generation aptable repository. 

This is "nice to have" features, but they are not absolutely required and
as they are complicated, I'd keep them for after the "required" features.

> Implement interaction with package  maintainer/mentor for upload package
> in official repository.

This is a "required" feature.

>    Deliverable 5
>        Implement web-interface for system. Included interface for
> registration and accepting external contributor, inclusion new package in
> VCS, web-frontend for VCS, status information about each package,
> contribution and people included in it maintenance.

Web-frontend for VCS ? That already exists as well
http://svn.debian.org/wsvn/

>    Deliverable 6
>        Implement closely integration infrastructure with Debian PTS, BTS,
> QA-team and Debian mentors(1).

What kind of integration do you have in mind?

>    Deliverable 7
>        Final code and report published.
> 
> 
> Project Details (2)
>    This project focused on maintenance packages which includes external
> contributions from non Debian Developers. It mostly be used for handling the
> maintenance of orphaned/unmaintained packages (3), but meant to be used in

I'm not so sure anymore that the handling of orphaned/unmaintained
packages would be the major use case.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/