www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <santiago.g...@gmail.com>
Subject Re: [dSCM] Use case: infra down for maintenance
Date Fri, 02 May 2008 07:47:56 GMT
El jue, 01-05-2008 a las 13:55 -0700, Doug Cutting escribió:
> Santiago Gala wrote:
> >> We do not want "peer to peer between developers" -- that is a violation of
> >> our development methodology, not a tool limitation.
> >>
> > 
> > Please, define $We. I'm a member of the ASF, active in a few PMCs, and
> > have been an officer for some yers, and I don't feel included in such
> > $We.
> I think Noel meant that we want project work to take place in public, on 
> mailing lists, in Jira and in Subversion.  Direct peer-to-peer exchanges 
> of patches are not a matter of public record, and should thus not be 
> encouraged as an Apache project development pattern.

Peer to peer exchanges can, and possibly should be for this purpose,
done in public. See the hundreds of repos at http://git.kernel.org/ that
are variations on the "master" linus tree. They all, literally, document
work that would be sunk on private working copies at the ASF. Direct
peer-to-peer exchanges of patches is bazaar, not cathedral, style. But
neither cathedral style is public without taking measures for
transparency (we need to *require* public issue tracker, public lists,
no irc or logged irc, irc decisiones were a tough item a few years
ago...) nor bazaar style is private by default (in fact, the use of
"pull" promotes that every developer has at least one public clone to
allow access to their changes, or else they are forced to send patches).

We should try to avoid framing the discussion into black/white
disjunctions. The line between

a) using patches or quilt or eclipse "local changes" as "private repos"
and an issue tracker or a development list to review the work and commit
to svn, and
b) having a full fledged, mandatory dSCM setup for the ASF

is a long line, full of places where people can stand. As Sander said,
as long as we have the master subversion repository documenting the
processes, one can use whatever is reasonable and interoperates with
issue tracking, patch generation and application, etc. 


> Doug
Santiago Gala

View raw message