[darcs-devel] [junkio@cox.net: [OT] mutually supervised developers]

[David Roundy]

Hi darcs developers,

Here's an interesting idea that came up on the git mailing list.  It'd be
reasonably easy to implement with darcs.  I imagine we could just allow
pull to accept multiple repositories and an --intersect flag (default would
probably to pull from all patches from all repositories).

What do you guys think? Anyone interested in working on this?

In case I was too vague, I'm imagining something like

darcs pull http://bar/darcs-juliusz http://baz/darcs-tomasz

would grab all the patches from all Polish darcs contributors.  But

darcs pull --intersect http://bar/darcs-juliusz http://baz/darcs-tomasz

would pull only patches that are in both Juliusz and Tomasz' repositories.
There'd need to be a bit of infrastructure involved, but not too much, and
it seems like a natural (and useful) extension of the existing interface.

David.

----- Forwarded message from Junio C Hamano <junkio at cox.net> -----

Envelope-to: droundy at abridgegame.org
Delivery-date: Sat, 11 Jun 2005 17:19:40 -0400
To: git at vger.kernel.org
cc: Linus Torvalds <torvalds at osdl.org>, Petr Baudis <pasky at ucw.cz>
Subject: [OT] mutually supervised developers
From: Junio C Hamano <junkio at cox.net>

I think this is somewhat offtopic here, but I was wondering:

 - if a development model like this would make sense,

 - and if so if we would want GIT to support such a model,

 - and if so if the current GIT already offers such support,

 - and if not what kind of primitives at the core layer we would
   need to add.

Let's assume that a project is co-managed by a handful top-tier
developers and has an active development community.  There is
_the_ public repository that all users consider the canonical
starting point to base their work off of.  It would be like -git
snapshot tree or -mm tree in Linux 2.6 kernel.

These developers are all active in the community, and at times
are overenthusiastic.  Their own changes are usually quite good,
they also have good taste when accepting outside patches, but
they all tend to commit not-so-well-thought-out crapola of their
own from time to time to their own repository.

I am wondering if the world would be a better place if this
fictitious project sets up public repositories in the following
way:

 (1) each developer's own repository is public;

 (2) these developers pull from each other "only good stuff",
     rejecting things he or she feels questionable.  Let's
     forget that current GIT does not give a direct support for
     cherrypicking for now.

 (3) the public canonical repository is updated to contain the
     intersection (_not_ union) of these developer repositories.
     Let's also forget that current GIT does not have automated
     way to do such a thing.

This would give each developer an "adult supervision" by all the
other developers, because any stuff that somebody finds
questionable will not be included in the "intersection".  The
public canonical repository is essentially to contain the
community "concensus".

Applying the above outline literally is inpractical in that it
gives any slow (or just otherwise busy) developer an unintended
"veto" power to freeze the canonical tree, so the management of
the canonical repository part may need to be tweaked with
something like majority rule, but the basic idea is to help
people get mutual supervision to prevent them from spreading
crap they may later regret.

Would people find something like this arrangement workable and
worthwhile?

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

----- End forwarded message -----

-- 
David Roundy
http://www.darcs.net