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: [scm] Mob version control
Date Wed, 19 Mar 2008 20:25:00 GMT

El mié, 19-03-2008 a las 18:24 +0200, Jukka Zitting escribió:
> Hi,
> Mentioned by Santiago on
> http://memojo.com/~sgala/blog/2008/03/17/Mob-software. Any registered
> user can currently contribute using the most of our mailing lists,
> many wikis, and the issue trackers, but our version control system is
> strictly read-only to non-committers. I know there are many good
> reasons for keeping access to the official codebases limited, but how
> about providing tools for contributors to work together on example
> code, utility tools, experimental patches, etc. Many of our projects
> have "contrib" folders for code like that, but often such code ends up
> rotting due to the relatively high barrier of sending and applying
> patches.
> What would it take to make parts of our version control system
> read-write to all contributors? (Hmm, "non-committer" wouldn't really
> be an applicable term... :-) Just like we have separate "private" and
> "asf" repositories, could we add a new one like "contrib" that any
> registered contributor could use? I'm sure that would require lots of
> extra maintenance, but are there fundamental issues that would prevent
> that or at least make it undesirable?

While I found it interesting and provocative enough as a concept to
merit a blog entry, I'm not sure it is exactly a good idea. Unless you
want to assume all the previous "mob" commits in the same code base, my
work flow for a "mob" branch would probably be something like:

- clone the repository
- create a private branch off the "master" or a topic branch
- git cherry-pick <patch> for patch in mob if patch == interesting :)
- edit, commit, test, review, amend, etc. until satisfied
- git checkout mob
- git cherry-pick <whatever commit or set of from my private branch>
- git push mob

on the other side of the fence, other people could cherry-pick those
commits and keep the "hybridization" going on. Or the maintainer pick
enough of those to make a difference...

Nothing in this process really requires the code continuity. The use of
git here would be oriented to produce "sane" commits. A sane commit is a
patch that includes some meta information, basically author, date,
branch and parent commit, though the "mob" branch is suspect unless a
maintainer is diligently cleaning it to a reasonable state.

I'd rather have those commits formatted with something like
git-format-patch and attached to some issue tracker, which is how I see
this "mob" branch working: a sort of "patch processor" :)

A patch processor is not at all a little thing: having people able to
generate sane patches and having some sort of tool validating those
lowers significantly entry barriers. While git is a tool with a
significant entry barrier, it also brings significant benefits.

> BR,
> Jukka Zitting
Santiago Gala

View raw message