couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian>
Subject Re: Git process description from an ASF project
Date Fri, 25 Nov 2011 19:23:43 GMT
This is useful, I will aggregate to the wiki, but first, have some
comments/questions inline below:

> [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?]

RTC (review then commit) is how we currently operate. I would like us
to continue operating in this fashion. The test here, is that we use
the wonderfully user friendly GitHub pull request mechanism to do the
reviewing part. The committing part to the canonical ASF repo would be
done once a review is deemed successful (CLA in place, IP clear).

Is this going to be acceptable?

> [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?]

I think the process outlined above works nicely. Note, the GitHub part
isn't a requirement (obviously) but rather just another channel. Email
patches work too but are, of course, more work and, frankly, unlikely
from our audience.

> [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
> easier)
> [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?]

My thoughts are that we treat a patch, regardless of origin, the same.
It has be cleared of IP concern and merged to the canonical repo
hosted by the ASF by a committer.

> 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?]

This is an interesting question. I pinged the GitHub guys to see about
their enterprise package. I think we could arrange getting it
subsidized and/or donated to the ASF. Regardless, not a big infra q.

> 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.

Guess this is a personal pref, I prefer the oposite!

> 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.

I don't think the origin of a patch has much to do w/ the local
developer workflow and the larger project workflows. We branch heavily
on a project basis for longer lived features and, most of us, do local
topic branches per feature/bug. Its a strength of Git to branch
cheaply, so we do.

> [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?]

I think there are some good practices we could encourage but certainly
do not think we'd want to enforce a particular flow. Projects with a
few contributors don't need to go crazy w/ branching but ones like
PhoneGap couldn't live without it.

> [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.

Thats interesting b/c, and this is my personal case, most developers
using Git have extensive experience w/ SVN. I tend to find that the
oposite is not true. Anyhow, not relevant to the ASF from my
perspective. The ASF is about the community over the code and in that
spirit support for Git is emerging satisfying both dev communities.

> [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?]

Pretty great question. I'm of the opinion that shuffling code between
RCS systems creates more problems than it solves. A developer should
have acumen in both technologies these days. Should a project
accommodating a developer whom refuses to pick up the RCS chosen by a
project? I don't think so.

> [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?]

A plain Git repo is definitely a good start but the ability to browse
via a browser is super handy! (Gitorious or Gitolite accommodate that
use case.) GitHub's faculties for forking, reviewing, commenting are
also super useful but not mandatory. Just better ergonomics.

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

Git tag works essentially the same. The Couch guys have outlined a
nice workflow w/ signed tagging on their wiki here:

(Maybe I should add more detail there?)

> 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.

Thank you!!!!

View raw message