camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Matèrne (jhm) <>
Subject AW: Github
Date Wed, 13 Feb 2013 21:04:28 GMT
I wrote some paragraphs about using Git.
I thought about modifying the (New
paragraph between "Submitting patches" and "Becoming a committer").
But because this is a bigger change I want to discuss that before.

So what do you think?


h2. Working with Git

While several committer are working with Git, it is not the primary version
control system at Apache Software Foundation. This is because the ASF has to
ensure that each commit into the codebase is correct licensed. With the
current VCS - Subversion - only committers with a signed CLA have write

But there are several ways how Git users could improve Camel with their
prefered tool:
* git-svn
* Apache Git Mirror
* Pull request at Github

The minor "problem" is creating the local repository connected to the
official repository. Next step is modifying the codebase. The major
"problem" then is getting the modifications back to the official ASF
Depending on the chosen way these steps differ which is short described

h3. git-svn

With Git you cannot fork another Git repository - you also could "fork" a
subversion repository.
git svn clone <TargetDirectory>

If you have write access to the codebase you could fork from the
https-adress and just "push" your changes back:
git svn dcommit -m "message"

Without that privilege you could follow the [recommended
workflow|]: working on a
feature branch, create a patch and attach it to Jira. Attaching to Jira has
the benefit for the community that you are enforced to grant explicitly the
license to the ASF.
git format-patch origin/trunk

h3. Apache Git Mirror

Forking the Git repo from here is much smoother, because you are forking a
"real" Git repo.
git fork git:// <TargetDirectory>

Bringing your modifications back to Apache is the [same workflow as
described before|].

Drawback of this Apache Git repository is that it is a "mirror" with a day
relay. So you are one day behind the community ...

h3. Pull request at Github

There is also a Git [repository at Github|]
which you could fork. Then you work on a new feature branch and send a pull
request. For granting the license you also should create a Jira issue with a
reference to that pull request. One of the committers then could bring that
changesets to the ASF codebase via his/her own local repository.
After closing the Jira issue you have to close the pull request because we
can't do that... 

Same drawback here - it is one day behind ...

h3. More resources

Git is not a brand new technology and therefore Camel is not the only ASF
project thinking about using it. So here are some more resources you mind
find useful:
* Some basic notes about git@asf
* List of mgit-mirrors at ASF
* More Git infos from Apache  

-----Ursprüngliche Nachricht-----
Von: Daniel Kulp [] 
Gesendet: Dienstag, 5. Februar 2013 15:31
An:; Jan Matèrne
Betreff: Re: Github

It is acceptable as issuing a pull request shows intent to contribute.

However, we have no way to close pull requests after we pull them.   In
general, if we pull the request, we then have to send a note back to the
original requester to have them close it.   Not a huge deal, but an extra
step.   That said, it's not a bad thing to have the original author verify
that the code was completely pulled correctly and such.


On Feb 5, 2013, at 8:10 AM, Jan Matèrne <> wrote:

> I have seen some "accepted pull requests" here on the list.
> Are pull requests "officially accepted" as patches?
> (new Jira issue with link to the pull request?)
> Jan

Daniel Kulp - Talend Community Coder -

View raw message