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: [email protected] Main development mailinglist [EMAIL PROTECTED] Debian BTS mails [EMAIL PROTECTED] 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. [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
