couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Git process description from an ASF project
Date Fri, 25 Nov 2011 00:18:24 GMT
Below are a set of comments and process descriptions adopted by
Deltacloud in relation to Git.

This comes from a private discussion and I only have permission to
repeat the words of David Luttekort (other posters did not withhold
permission, but they've not granted it explicitly, so I'm being
cautious, as a result I've edited Davids words occasionally so they
make sense where I've cut a previous comment).

I wonder if this content would be useful for the wiki or for driving
discussion about whether these are optimal approaches. I'm not a git
user (at least not in a project with more than two committers) so I
don't feel qualified to comment directly.

David says (I've injected a few comments/questions in [square brackets]):

I'll share some of the experiences that Deltacloud had; since the
project started on git, and switched to svn only because of entering the
ASF incubator, the project's workflows and conventions are about as
close as you can get to a git-only project while using git-svn.

[Push rates vary.] The workflow that Deltacloud (and a lot of git-centric
projects) use is review-before-commit, i.e. you post your proposed
patches on the mailing list, and should only commit them to the central
repo (now done via 'git svn dcommit') once at least one other person has
reviewed and ACK'd them.

[Most ASF projects operate on RTC for non-committers and CTR for
committers - is this likely to change with Git? Should it change? If
it need not change how do we ensure frequent pushed from committers?]

Patches from non-committers are committed by a committer on the
non-committer's behalf. Unfortunately, svn does not preserve the
separate Author and Committer roles that git does; we've therefore
switched to using 'Signed-off-by' to make sure we record the original
author of a patch. Of course, committers are responsible for checking
that patches they commit for others are backed by a CLA etc.

[The issue of SVN losing Author and Committer roles will disappear
with a Git central repo. What is the optimal process for handling
non-committer patches then?]

[People mostly share changes] on the mailing list, sending patches
around (for those who
haven't used git a lot: git makes it very easy to work with patch series
from others, in parallel to your own ongoing work) I personally find
github's model of sending merge requests and merging in other repos less
productive, in particular since I am very strict about maintaining a
linear master branch (git-svn forces that, but even for my non-ASF
projects do I insist on that, since it makes things like bisecting a ton

[Do you agree with these observations about GitHub merge requests? Are
we likely to find this model the norm. for people using GitHub? Do
other Git hosting environments encourage this workflow? What is the
optimal process for an ASF project?]

On occasion, I've uploaded a patch series to my page,
usually when the patches are huge and there is danger that they get
mangled in email.

[Does the ASF need some facility for this?]

In other projects, I've merged patches directly from other people's
repos, but as I said, I find that more annoying than applying a series
of patches directly.

> Branches in the ASF repository, or are people hosting them elsewhere?

For Deltacloud, we do not have any public branches. I think there were
one or two occasions in the pre-incubator days where we had a public
branch because we did a fundamental overhaul of the codebase and didn't
want to disturb the ongoing work on the master branch.

Whether you see a lot of public branches in a git project depends a lot
on how the project takes in contributions: via merge from other git
repos, or through patches posted to a mailing list. But even when
contributions come through merging of other git repos, you rarely see
branches in the canonical git repo.

There, you'd expect to see branches for exactly the same reasons you'd
see them in svn: to support longer-lived work that deviates from master.

[There's that same alternative process again? Any more comments in
this context? Should ASF projects be encouraged to follow one process
and not the other? Should it be left to individual projects?]

[How git affects the community]  highly depends who the community
members are: if they have a strong
git background, they'll be unhappy with svn; if they have a strong svn
background, they'll be unhappy with git. And not just the tools, but
also the differing workflows these tools accomodate.

[If a project moves to Git how to we minimise the pain for SVN users?
If a project stays with SVN are the Git mirrors we currently have the
best we can do for Git users? Can projects that stay on SVN benefit
from lessons learned in the GIt projects?]

[GitHib is not necessary to get the most from Git] IMHO, a gitweb
instance would be good enough for Deltacloud; a gitorious
instance of course much shinier. Whatever infra feels is the best tool
from their side would be fine by me.

[Is a plain vanilla Git repo enough? What do we *need*? What would add
additional value?]

On the subject of tagging releases; I've
only been doing this on my private git repo, but think it would be a
sensible recommendation for public repos: I generally tag releases and
release candidates using 'git tag -s release-1.2.3-rc7' at the same time
I run 'git svn tag'. The important thing is to pass '-s' to create a GPG
signed tag so that it is later reproducible without any doubt from what
state of the source repo the release artifacts were generated.

[In SVN tagging of releases is a critical part of our release
management processes. What are the equivalents in Git?]

Thanks to David for taking the time to share his experiences and
giving me permission to post them to a public list. Thanks in advance
to the git experts here for using this in whatever way is most
appropriate to move us forwards.


View raw message