On Jun 11, 2008, at 10:18 AM, Doug Cutting wrote:
David Reiss wrote:
Git is set up. Info here: http://wiki.apache.org/thrift/
GitRepository
I need to figure out how Git fits into the Apache development style.
Git has not been used much at Apache, certainly not in any project
that I've been involved in. I also have never used Git and speak
largely from ignorance.
Actually Git is pretty much a superset of subversion. I have quite a
bit experience with both pure git open source project and git-svn at
work to know that they can coexist seamlessly, with git users having
more freedom and convenience in their ways of development.
It should be noted that there have been flamewars within Apache
about the use of Git, and many feel that it doesn't belong here. I
don't want this discussion to degenerate that way, and am trying to
address this with an open mind and hope that others will too.
Apache places building better community over better code as the
highest priority of a project. Healthy communities build better
code long-term (or something like that). One of the hallmarks of
Apache communities is transparency in communications, providing a
level playing field for all members of the community. For example,
IRC is acceptable for casual conversations, but decisions about
changes to the project must be made on project mailing lists, so
that everyone, no matter timezone, etc., can contribute to the
discussion equally. It's also important to have a single venue for
discussion, patches, bugs, etc., so that everyone sees the same
information.
Some projects operate in a review-then-commit (RTC) mode, where,
before a patch may be committed it must be reviewed by another
committer. Other projects operate in commit-then-review (CTR), where
committers are expected to monitor commit messages and can veto
changes retroactively. (Some projects use different modes for trunk
than release branches.)
http://www.apache.org/foundation/glossary.html#CommitThenReview
I've mostly worked on RTC projects. In this case, it is important
that each patch is equally visible and easily applicable by every
committer. If some developers are using Git and some are not, how
will this work? Will every patch still be posted as a flat file in
Jira?
The development model of Git itself is RTC. Git fits the model
perfectly. Git patches has more information (author and its parent
commits) so that they can be merged with less pain than vanilla
patches. Attaching vanilla patches to Jira is a very backward way (I
tried to follow SOLR-303 and it was not pretty) of sharing patches.
One of the easiest ways for Git users to share repository currently is
using github.com (I think David needs to update that one as well for
post conversion repository). People can look at a series patches
easily using its web interface or they can simply post the patches to
a mailing list. The maintainer of official repository can quickly
merge from Git contributors' reviewed branches with the proper credit
and history *automatically*. The subversion + patches model places
much more burdens on "committers" who need to apply the patches and
maintain the credits with much less powerful tools.
One possibility might to declare that all members of the Thrift
community will use Git, and that patches will be shared via a shared
Git repository. Another possibility is that, in Jira, instead of
attaching patches as flat files, one might add links to a patch in
the Git repo. However this seems nearly equivalent to using
Subversion in CTR mode.
It's not equivalent, as Git patches are not in the official repo
before it's merged by the maintainer. The patch urls would point to
contributors own public repositories.
So, in summary, non-gitters like myself need to understand how we
expect transparent collaboration to function with Git. What is the
review model? It is unacceptable to have subsets of the community
sharing patches that are not yet available to the entire community.
When a patch is first made available for review, it must be made
available to all members of the community. Does this mean we all
need to use Git
Subversion users can still use the old way, attaching patches to jira
and let one of the subversion "committers" apply and commit the
changes. Git users would just publish their urls and ask the mailing
list to review the patch with better UI and then "maintainers" to pull
their changes.
Hope it clear things up a bit.
__Luke
P.S. I use "maintainers" to refer to people like David who maintains
the official repository, as everyone is a committer in Git.
