camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Matèrne (jhm) <apa...@materne.de>
Subject AW: AW: Github
Date Thu, 14 Feb 2013 05:26:56 GMT
Hello Hadrian,

some of the came via this mailing list, some of them via Google ;)


Jan

-----Ursprüngliche Nachricht-----
Von: Hadrian Zbarcea [mailto:hzbarcea@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:dkulp@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 <jan@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
> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder - 
> http://coders.talend.com
>
>


Mime
View raw message