Re: [long] Dpkg Team Organisation/Status
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@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
Reply to: