[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@lists.debian.org
Main development mailinglist
debian-dpkg-bugs@lists.debian.org
Debian BTS mails
debian-dpkg-cvs@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@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@debian.org>
www: http://www.djpig.de/
Reply to: