You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Jan Matèrne <ja...@materne.de> on 2013/02/05 14:10:27 UTC
Github
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
Re: Github
Posted by Henryk Konsek <he...@gmail.com>.
Hi Jan,
> Are pull requests "officially accepted" as patches?
> (new Jira issue with link to the pull request?)
That's right - this is accepted approach. :)
--
Henryk Konsek
http://henryk-konsek.blogspot.com
AW: AW: Github
Posted by "Jan Matèrne (jhm)" <ap...@materne.de>.
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 <ja...@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
>
>
Re: AW: Github
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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 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 <ja...@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
>
>
AW: AW: Github
Posted by "Jan Matèrne (jhm)" <ap...@materne.de>.
After getting one +1 and no -1 I added that to the wiki page.
Jan
-----Ursprüngliche Nachricht-----
Von: Christian Müller [mailto:christian.mueller@gmail.com]
Gesendet: Mittwoch, 13. Februar 2013 22:19
An: dev@camel.apache.org
Betreff: Re: AW: Github
+1
Sent from a mobile device
Am 13.02.2013 22:05 schrieb "Jan Matèrne (jhm)" <ap...@materne.de>:
> 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 <ja...@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
>
>
>
Re: AW: Github
Posted by Christian Müller <ch...@gmail.com>.
+1
Sent from a mobile device
Am 13.02.2013 22:05 schrieb "Jan Matèrne (jhm)" <ap...@materne.de>:
> 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 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 <ja...@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
>
>
>
AW: Github
Posted by "Jan Matèrne (jhm)" <ap...@materne.de>.
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 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 <ja...@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
Re: Github
Posted by Daniel Kulp <dk...@apache.org>.
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 <ja...@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