www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: [dSCM] Use case: infra down for maintenance
Date Fri, 02 May 2008 07:56:29 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

And the concrete proposal is? what?

Every project should have a wiki(?) which documents public repos which are sandboxes of prople
participating in the
project (whether they are committers or folks submitting patches)

And/OR

When someone creates a JIRA, they should have an option to specify a public git repo location
and revision # for their
patch.

thanks,
dims

Santiago Gala wrote:
| 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.
|
| Regards
| Santiago
|
|> Doug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iD8DBQFIGsktgNg6eWEDv1kRAveBAJ4pRx4+PIEp2JMORCJsgWIUzwIlZACdG68/
AgtmLzK8XuJGkoPpD/5ENqs=
=hr4E
-----END PGP SIGNATURE-----

Mime
View raw message