You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-dev@apache.org by Jukka Zitting <ju...@gmail.com> on 2008/03/19 17:24:14 UTC
[scm] Mob version control
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?
BR,
Jukka Zitting
Re: [scm] Mob version control
Posted by Santiago Gala <sa...@gmail.com>.
El jue, 20-03-2008 a las 11:59 +0200, Jukka Zitting escribió:
> Hi,
>
> On Wed, Mar 19, 2008 at 10:25 PM, Santiago Gala <sa...@gmail.com> wrote:
> > 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" :)
>
> Exactly. There are many cases where a normal patch produced by svn
> diff is not good enough. For example anything that deals with renames,
> copies, or binary files is difficult to communicate in the normal
> patch format. Also the "sequence of changes" use case requires
> something more than a normal patch. A mob branch or source repository
> would be one solution to such needs.
>
> > 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.
>
> There are also other possible process improvements, for example we
> could point FishEye/Crucible to a mob svn repository to get improved
> tooling for code reviews.
>
I have never used FishEye/Crucible, but I just found and installed
reviewboard (in 30 minutes counting the time to get git-svn to suck off
their whole svn repository): http://code.google.com/p/reviewboard/ Now I
had django already and I'm currently developing django stuff, so I play
with a certain advantage. Still, I don't think it should take more than
a couple of hours to anybody.
It is free software, MIT licensed, runs on top of django and supports a
number of SCMs (I've tested git and mercurial for the moment). It looks
pretty good, incorporating patch review features, etc. I have one local
copy, and I'm wondering if we should give it a look here for our
infrastructure. See an example working for postgresql:
http://reviewdemo.postgresql.org/r/10/
Patch revision processes and quality of commit logs
---------------------------------------------------
Actually, this part of the discussion is touching a nerve for me: I have
a concern about the way we typically write subversion commit log
entries. A lot of the information that should be "bundled" together with
the code in the commit is instead split in JIRA comments, and JIRA is
being used a lot for design decisions, instead of putting them in the
commit logs.
While I see that the issue tracker data is archived, etc., I think one
feature of distributed scm is that it is handy for offline/local
browsing. For instance, I'm finding that a a "git svn rebase" followed
by a gitk is better to read the code changes than passing through the
commit mails, by an order of magnitude. When I need to jump to the issue
tracker links and back, it becomes slower, not to mention the fact that
it cannot be longer done offline.
Having more discipline, git-like, I think would help the whole quality
indices here. One summary line making explicit what the commit contains,
and then a number of paragraphs of detailed explanations, including
Signed-By:, Author:, etc.
Regards
Santiago
> BR,
>
> Jukka Zitting
--
Santiago Gala
http://memojo.com/~sgala/blog/
Re: [scm] Mob version control
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Mar 19, 2008 at 10:25 PM, Santiago Gala <sa...@gmail.com> wrote:
> 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" :)
Exactly. There are many cases where a normal patch produced by svn
diff is not good enough. For example anything that deals with renames,
copies, or binary files is difficult to communicate in the normal
patch format. Also the "sequence of changes" use case requires
something more than a normal patch. A mob branch or source repository
would be one solution to such needs.
> 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.
There are also other possible process improvements, for example we
could point FishEye/Crucible to a mob svn repository to get improved
tooling for code reviews.
BR,
Jukka Zitting
Re: [scm] Mob version control
Posted by Santiago Gala <sa...@gmail.com>.
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
http://memojo.com/~sgala/blog/
Re: [scm] Mob version control
Posted by Mark Thomas <ma...@apache.org>.
Thilo Goetz wrote:
> Mark Thomas wrote:
>> Thilo Goetz wrote:
>>> It is my understanding that anything that's in our SVN is an Apache
>>> release.
>>
>> This is not (necessarily) the case. See
>> http://www.apache.org/dev/release.html
>>
>> Mark
>
> Oops, sorry. I meant distribution, not release. Anything
> that's in SVN, we're distributing, it's available to the general
> public from an Apache server.
Until we do a release, we have far more leeway. For example, it doesn't
(usually) cause us a problem if someone attaches a patch for Tomcat to a
bugzilla issue and they have copied from code Glassfish. We just don't
apply the patch.
It is only a problem if we apply the patch to svn and cut a release. Even
then, if it is done unknowingly and we move quickly to rectify the problem
when it is pointed out, there are (usually) no issues.
Bottom line, a repository that is open to the public is no different to our
public wiki or our public issue trackers. There should not be an issue
providing we continue to review patches that are committed to the
'internal' repository. For a definitive opinion you can use the
legal-discuss list.
Mark
Re: [scm] Mob version control
Posted by Thilo Goetz <tw...@gmx.de>.
Mark Thomas wrote:
> Thilo Goetz wrote:
>> It is my understanding that anything that's in our SVN is an Apache
>> release.
>
> This is not (necessarily) the case. See
> http://www.apache.org/dev/release.html
>
> Mark
Oops, sorry. I meant distribution, not release. Anything
that's in SVN, we're distributing, it's available to the general
public from an Apache server.
--Thilo
Re: [scm] Mob version control
Posted by Mark Thomas <ma...@apache.org>.
Thilo Goetz wrote:
> It is my understanding that anything that's in our SVN is an Apache
> release.
This is not (necessarily) the case. See http://www.apache.org/dev/release.html
Mark
Re: [scm] Mob version control
Posted by Thilo Goetz <tw...@gmx.de>.
Jukka Zitting wrote:
> Hi,
>
> On Wed, Mar 19, 2008 at 6:34 PM, Erik Abele <er...@codefaktor.de> wrote:
>> Apart from the (quite essential) maintenance overhead there might be
>> legal concerns, e.g. we would be publishing/endorsing things not
>> covered under a CLA etc. etc...
>
> We already do that in our wikis, the issue trackers, and of course
> also on the mailing lists. Of course we'd need to apply legal
> oversight when migrating code from the "contrib" repository to the
> official codebases, but we already have similar processes in place for
> normal patches and documentation contributions that flow from the
> wikis to project web sites.
>
>> IMHO it would also kind of under-mine our core principle of
>> meritocracy ("hey, i can write to the contrib repo so why should i
>> care to become a committer or work within the existing community");
>> not that it couldn't be useful in e.g. recruiting new committers or
>> fostering the community but I think there's some dangerous potential
>> here.
>
> The crucial difference would be that nothing in the contrib repository
> could become a part of an official release without explicit action
> (i.e. legal oversight and merging to the official codebase) by a
> "real" committer. But it's a good point to be considered.
I do think Erik has a point. I'm no legal expert by any means, but
from my current understanding of affairs, I think there may some
obstacles to the idea. Maybe I'm wrong, though.
It is my understanding that anything that's in our SVN is an Apache
release. So we have no leeway here: if it's in SVN, due diligence
needs to be applied. So I think anybody committing to SVN, no matter
the branch, would need a CLA in place. Patches are different because
they *are* applied by a committer, and it's the committers' responsibility
to make sure that what they're committing clean IP-wise.
More legalese: suppose a new feature got implemented in the contrib
area, and the project wants to merge this new feature into their
trunk. Are the tools good enough so the provenance of the code that
gets merged in can be determined? Can we tell who all contributed
to that feature? With a patch, we do know.
--Thilo
>
> BR,
>
> Jukka Zitting
Re: [scm] Mob version control
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Mar 19, 2008 at 6:34 PM, Erik Abele <er...@codefaktor.de> wrote:
> Apart from the (quite essential) maintenance overhead there might be
> legal concerns, e.g. we would be publishing/endorsing things not
> covered under a CLA etc. etc...
We already do that in our wikis, the issue trackers, and of course
also on the mailing lists. Of course we'd need to apply legal
oversight when migrating code from the "contrib" repository to the
official codebases, but we already have similar processes in place for
normal patches and documentation contributions that flow from the
wikis to project web sites.
> IMHO it would also kind of under-mine our core principle of
> meritocracy ("hey, i can write to the contrib repo so why should i
> care to become a committer or work within the existing community");
> not that it couldn't be useful in e.g. recruiting new committers or
> fostering the community but I think there's some dangerous potential
> here.
The crucial difference would be that nothing in the contrib repository
could become a part of an official release without explicit action
(i.e. legal oversight and merging to the official codebase) by a
"real" committer. But it's a good point to be considered.
BR,
Jukka Zitting
Re: [scm] Mob version control
Posted by Erik Abele <er...@codefaktor.de>.
On 19.03.2008, at 17:24, Jukka Zitting wrote:
> ...
> 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?
Apart from the (quite essential) maintenance overhead there might be
legal concerns, e.g. we would be publishing/endorsing things not
covered under a CLA etc. etc...
IMHO it would also kind of under-mine our core principle of
meritocracy ("hey, i can write to the contrib repo so why should i
care to become a committer or work within the existing community");
not that it couldn't be useful in e.g. recruiting new committers or
fostering the community but I think there's some dangerous potential
here.
Cheers,
Erik