Hello Hadrian, some of the came via this mailing list, some of them via Google ;)
Jan -----Ursprüngliche Nachricht----- Von: Hadrian Zbarcea [mailto:hzbar...@gmail.com] Gesendet: Mittwoch, 13. Februar 2013 22:56 An: dev@camel.apache.org Betreff: Re: AW: Github Thanks Jan, Were you aware of the Apache git site [1], especially the documentation [2] and wiki [3] links? Hadrian [1] http://git.apache.org/ [2] http://www.apache.org/dev/git.html [3] http://wiki.apache.org/general/GitAtApache On 02/13/2013 04:04 PM, Jan Matèrne (jhm) wrote: > I wrote some paragraphs about using Git. > I thought about modifying the > http://camel.apache.org/contributing.html (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? > > Jan > > > 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 access. > > 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 > repository. > Depending on the chosen way these steps differ which is short > described here. > > h3. git-svn > > With Git you cannot fork another Git repository - you also could > "fork" a subversion repository. > {code} > git svn clone https://svn.apache.org/repos/asf/camel/trunk > <TargetDirectory> {code} > > If you have write access to the codebase you could fork from the > https-adress and just "push" your changes back: > {code} > git svn dcommit -m "message" > {code} > > Without that privilege you could follow the [recommended > workflow|https://git-wip-us.apache.org/docs/workflow.html]: working on > workflow|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. > {code} > git format-patch origin/trunk > {code} > > h3. Apache Git Mirror > > Forking the Git repo from here is much smoother, because you are > forking a "real" Git repo. > {code} > git fork git://git.apache.org/camel.git <TargetDirectory> {code} > > Bringing your modifications back to Apache is the [same workflow as > described before|https://git-wip-us.apache.org/docs/workflow.html]. > > 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|https://github.com/apache/camel] > 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: > * http://wiki.apache.org/general/GitAtApache: Some basic notes about > git@asf > * http://git.apache.org/: List of mgit-mirrors at ASF > * https://git-wip-us.apache.org/: More Git infos from Apache > > > > > -----Ursprüngliche Nachricht----- > Von: Daniel Kulp [mailto:dk...@apache.org] > Gesendet: Dienstag, 5. Februar 2013 15:31 > An: dev@camel.apache.org; 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. > > Dan > > > > On Feb 5, 2013, at 8:10 AM, Jan Matèrne <j...@materne.de> 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?) >> >> >> >> https://github.com/apache/camel >> >> >> >> >> >> Jan >> > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog Talend Community Coder - > http://coders.talend.com > >
