[long] Dpkg Team Organisation/Status

Hi.

With me being more active again after some months of working on other
stuff in Debian, and with new people like Raphael and Ian getting commit
access to the SVN repository, I thought it might be a good idea to try
to assemble a little status report about the Dpkg team and mention some
areas where we might need to discuss about our future procedures.

Comments and corrections welcome. If someone wants to convert this mail
to a Team page at wiki.debian.org, feel free to do so.

Status
------

Resources:

debian-dpkg.TakeThisOut@lists.debian.org

Main development mailinglist

debian-dpkg-bugs.TakeThisOut@lists.debian.org

Debian BTS mails

debian-dpkg-cvs.TakeThisOut@lists.debian.org

Commit messages for the central VCS, currently the SVN repository

#debian-dpkg on OFTC

IRC channel where most of the current active developers hang around
Commit messages via the CIA bot

ssh+svn://svn.debian.org/svn/dpkg

SVN repository. A switch to a distributed VCS was suggested on the list
and there were no objections so far. Raphael is still trying to collect
as much of the development history (the arch part in particular) as
possible.

team.TakeThisOut@dpkg.org

Maintainer email address, I'm actually unsure who maintains that and of
the exact list of people behind that alias.

People:

with commit access:
Guillem Jover (most active contributor during the last year,
all areas)
Frank Lichtenheld (mostly bug fixing, mostly on dpkg-dev,
quiet the last months)
Nicolas FRANCOIS (po4a, install-info)
Christian Perrier (L10N coordination)
Raphael Hertzog (new dpkg-shlibdeps, not yet in trunk/)
Brendan O'Dea (worked on Wig-and-Pen unpack support, various dpkg-dev
bug fixes)

should get commit access soon:
Ian Jackson (nowadays Ubuntu dpkg maintainer, in the past author of a
great part of dpkg)

without commit access:
Tollef Fog Heen (worked on multiarch support, not merged)

plus a lot of translators.

Processes and Organisation:
---------------------------

SVN:

We have currently no clear policies about commits.

Proposal for some commit guidelines:

Small and/or trivial bug fixes and enhancements should go directly to
trunk/
Translation updates and additions should go directly to trunk.
Bigger patches should be discussed in the BTS and/or the mailing list
before committing.
For long going discussions it would probably best if interested parties
could prepare a summary of the discussion for the mailing list
before commiting/merging the result.
People with commit access should feel free to create branches in
branches/ to allow others easily to contribute to or to
experiment with proposed patches/features
Since there is no hierarchy between contributors, discussion should
preferably solved by consens, at least between the involved
dpkg Team members

TODO:
Ian and Guillem (and maybe others) need to solve their disagreements
about coding style in the C part of dpkg


Uploading:

There are currently no clear policies about uploads, but the last
uploads were at least announced and somewhat coordinated in #debian-dpkg
which was probably sufficient since all people that have contributed to the
new version were present.

Proposal for some guidelines:

If someone (with feels that enough changes have accumulated in trunk/ and that
it is stable enough to warrant an upload, he should announce his intent
at least 24h prior to the upload on the mailing list so that people have
the chance 1) veto the upload, 2) commit small fixes and/or translation
updates.
Exceptions from this rule are RC bug and/or regression fixes shortly
after a prior upload if no other changes have yet been committed to
trunk/ The upload should still be announced at least on #debian-dpkg and
preferably on the mailing list.


distributed VCS:

If we indeed switch to a distributed VCS we need to make a descision
about the future development model. There are some alternatives:

1) One person gets designated as release manager and manages the
"official tree". Uploads should only be made from this tree and all
other contributors either send patches to the mailing list, the BTS,
or request pulls by the release manager. This is how Scott organised
dpkg development in the arch period. The release manager can change,
but probably not too often.

[The advantage is that the release manager can act as a gate keeper
and policy enforcer, but he is also a singe point of failure]

2) There is no official tree. Uploads can be made by everyone and all
others will need to make sure to sync their trees after the upload so
that if they do the next upload, they don't loose any past commits.

[I honestly don't see this working reliably]

3) We create a shared "official" tree where a group of committers can
push directly. This is sort of the current model, just with enhanced
development possibilities aside from the official tree.

[This would be the least disruptive model, but it lacks a central
instance, which might or might not be an advantage]

Gruesse,
--
Frank Lichtenheld <djpig.TakeThisOut@debian.org>
www: http://www.djpig.de/


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Hi,

On Sat, 2007-07-14 at 20:23:19 +0200, Frank Lichtenheld wrote:
> With me being more active again after some months of working on other
> stuff in Debian, and with new people like Raphael and Ian getting commit
> access to the SVN repository, I thought it might be a good idea to try
> to assemble a little status report about the Dpkg team and mention some
> areas where we might need to discuss about our future procedures.

Thanks for assembling this mail!

> team.RemoveThis@dpkg.org
>
> Maintainer email address, I'm actually unsure who maintains that and of
> the exact list of people behind that alias.

Brendan maintains it AFAIK, and the current list is the one matching
Uploaders (the group that inherited the package from Scott).

> Processes and Organisation:
> ---------------------------
>
> SVN:
>
> We have currently no clear policies about commits.

I think we have had some kind of implicit policy. For example Nicolas
had a set of areas like l10n/i18n and trivial fixes where he was
committing freely, and for general/complex fixes he was using commit
after approval from one of the Uploaders.

> Proposal for some commit guidelines:
>
> Small and/or trivial bug fixes and enhancements should go directly to
> trunk/
> Translation updates and additions should go directly to trunk.
> Bigger patches should be discussed in the BTS and/or the mailing list
> before committing.
> For long going discussions it would probably best if interested parties
> could prepare a summary of the discussion for the mailing list
> before commiting/merging the result.
> People with commit access should feel free to create branches in
> branches/ to allow others easily to contribute to or to
> experiment with proposed patches/features
> Since there is no hierarchy between contributors, discussion should
> preferably solved by consens, at least between the involved
> dpkg Team members

Probably the most notorious distinction has been between Uploaders and
the rest, although there has not been any kind of explicit hierarchy
among Uploaders as you said. I don't think we have had much trouble
with decision making with the current group of people, in general when
something was clear cut we went ahead (most of the time after having
stated one's opinion on the relevant bug report or mailing list thread),
if some of us had some doubt, or were undecided/indiferent then we
asked the rest for comments, etc.

About the hierarchical organization, it didn't seem needed with such a
small bunch of people, and the way the group was formed greatly
influenced this as well. As we add more people I'm unsure if it might
be preferable.

> TODO:
> Ian and Guillem (and maybe others) need to solve their disagreements
> about coding style in the C part of dpkg

I'd say this needs to be solved globally, including the perl parts which
might be more inconsistent than the C/C++ parts, more so now that we
have the opportunity with the perl modularization.

> Proposal for some guidelines:
>
> If someone (with feels that enough changes have accumulated in trunk/ and that
> it is stable enough to warrant an upload, he should announce his intent
> at least 24h prior to the upload on the mailing list so that people have
> the chance 1) veto the upload, 2) commit small fixes and/or translation
> updates.
> Exceptions from this rule are RC bug and/or regression fixes shortly
> after a prior upload if no other changes have yet been committed to
> trunk/ The upload should still be announced at least on #debian-dpkg and
> preferably on the mailing list.

I suppose the amount of time should vary depending on the magnitude of
changes accumulated, or the possible disruption, at least that's how I
remember having been doing the announcements in the past. I'd say for
most of the cases 24h seems too short as people might not be able to
react that fast (but of course there might be cases where it's
perfectly fine or even too long!).

> distributed VCS:
>
> If we indeed switch to a distributed VCS we need to make a descision
> about the future development model. There are some alternatives:
>
> 1) One person gets designated as release manager and manages the
> "official tree". Uploads should only be made from this tree and all
> other contributors either send patches to the mailing list, the BTS,
> or request pulls by the release manager. This is how Scott organised
> dpkg development in the arch period. The release manager can change,
> but probably not too often.
>
> [The advantage is that the release manager can act as a gate keeper
> and policy enforcer, but he is also a singe point of failure]

This would be kind of fine, although is more burden for the RM, and
the single point of failure is a problem I think we should try to
avoid.

> 2) There is no official tree. Uploads can be made by everyone and all
> others will need to make sure to sync their trees after the upload so
> that if they do the next upload, they don't loose any past commits.
>
> [I honestly don't see this working reliably]

Me neither.

> 3) We create a shared "official" tree where a group of committers can
> push directly. This is sort of the current model, just with enhanced
> development possibilities aside from the official tree.
>
> [This would be the least disruptive model, but it lacks a central
> instance, which might or might not be an advantage]

Hmm I don't understand your comment. If we have a shared tree, that
would be the central one, or are you referring to something different?
This alternative would seem the preferable to smooth the transition,
and we could switch to something else (if desired) afterwards.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org