You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Daniel Pocock <da...@pocock.pro> on 2014/12/02 09:31:06 UTC
contribution guidelines, pull requests?
I notice none of my recent pull requests has been merged. This makes it
awkward because I don't want my own work to diverge significantly if
more time passes and I don't want other contributors or users to
potentially waste time on issues that I have worked on.
I've tried to make each contribution a discrete fix so it is easier to
review and revise if necessary. However, some of my patches already
overlap with each other and extra effort may need to be expended
resolving merge conflicts if the code diverges further.
I looked at the contribution guidelines here:
http://camel.apache.org/contributing.html
and I understand that the old process required patches for bugs to be
submitted in JIRA
Under the Github heading in that page, it is not clear if every pull
request must reference a JIRA issue.
For example, the java.sql.Timestamp type converter doesn't fix any bug,
it is a new feature:
https://github.com/apache/camel/pull/344
so do I still need to open a JIRA issue for that or is the pull request sufficient?
Re: contribution guidelines, pull requests?
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Dec 2, 2014 at 10:39 AM, Daniel Pocock <da...@pocock.pro> wrote:
> On 02/12/14 09:37, Claus Ibsen wrote:
>> Hi
>>
>> We do not apply PRs asap - people are busy with work.
>
> If Camel has become too big to maintain, then why not split off some of
> the modules to be community maintained? E.g. maybe I can just commit
> directly on the camel-smpp module if it is a separate Github project.
>
> The contributor documentation tells people to make separate branches for
> each issue they work on. But if pull requests are not being merged
> promptly, that is not an efficient way for contributors to spend their
> own work time, it may be better for contributors to create a series of
> patches on a feature branch and that can then be merged in one go when
> somebody has reviewed it.
>
> In any case, can you please clarify whether every pull request must have
> a JIRA, even if it is not fixing a bug?
>
>>
>> Also we really favor unit tests when you add new stuff.
>>
>> And btw the converter is wrong, as you should not return null, and the
>> parameter provided by Camel is never null either.
>
> I just used the same logic that I saw in this existing type converter
> code in core:
>
> https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/converter/DateTimeConverter.java
>
> If that is not a good example, could you please update it or point me to
> a better one and I'll fix my pull request?
>
Yeah sorry we have a few type converters that use the old time
behavior. I have logged a ticket to cleanup this
https://issues.apache.org/jira/browse/CAMEL-8108
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/
Re: contribution guidelines, pull requests?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Please have more patience.
Your PR asap its only 4 days ago, and this is just the start of the
working week.
Also type converters in camel-core need to be registered manually, see
org.apache.camel.impl.converter.CorePackageScanClassResolver
And the contributing guide tells you to provide unit tests.
And yeah a CAMEL ticket is preferred as well so we track the issue
from Apache, and can use that JIRA ticket to mark which versions the
code has been included in.
And yeah that existing coverer class is wrong as well, should not deal
with null parameter - though that was needed in the early days of
Camel, and is a kinda leftover.
On Tue, Dec 2, 2014 at 10:39 AM, Daniel Pocock <da...@pocock.pro> wrote:
> On 02/12/14 09:37, Claus Ibsen wrote:
>> Hi
>>
>> We do not apply PRs asap - people are busy with work.
>
> If Camel has become too big to maintain, then why not split off some of
> the modules to be community maintained? E.g. maybe I can just commit
> directly on the camel-smpp module if it is a separate Github project.
>
> The contributor documentation tells people to make separate branches for
> each issue they work on. But if pull requests are not being merged
> promptly, that is not an efficient way for contributors to spend their
> own work time, it may be better for contributors to create a series of
> patches on a feature branch and that can then be merged in one go when
> somebody has reviewed it.
>
> In any case, can you please clarify whether every pull request must have
> a JIRA, even if it is not fixing a bug?
>
>>
>> Also we really favor unit tests when you add new stuff.
>>
>> And btw the converter is wrong, as you should not return null, and the
>> parameter provided by Camel is never null either.
>
> I just used the same logic that I saw in this existing type converter
> code in core:
>
> https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/converter/DateTimeConverter.java
>
> If that is not a good example, could you please update it or point me to
> a better one and I'll fix my pull request?
>
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/
Re: contribution guidelines, pull requests?
Posted by Daniel Pocock <da...@pocock.pro>.
On 02/12/14 09:37, Claus Ibsen wrote:
> Hi
>
> We do not apply PRs asap - people are busy with work.
If Camel has become too big to maintain, then why not split off some of
the modules to be community maintained? E.g. maybe I can just commit
directly on the camel-smpp module if it is a separate Github project.
The contributor documentation tells people to make separate branches for
each issue they work on. But if pull requests are not being merged
promptly, that is not an efficient way for contributors to spend their
own work time, it may be better for contributors to create a series of
patches on a feature branch and that can then be merged in one go when
somebody has reviewed it.
In any case, can you please clarify whether every pull request must have
a JIRA, even if it is not fixing a bug?
>
> Also we really favor unit tests when you add new stuff.
>
> And btw the converter is wrong, as you should not return null, and the
> parameter provided by Camel is never null either.
I just used the same logic that I saw in this existing type converter
code in core:
https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/converter/DateTimeConverter.java
If that is not a good example, could you please update it or point me to
a better one and I'll fix my pull request?
Re: contribution guidelines, pull requests?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
We do not apply PRs asap - people are busy with work.
Also we really favor unit tests when you add new stuff.
And btw the converter is wrong, as you should not return null, and the
parameter provided by Camel is never null either.
On Tue, Dec 2, 2014 at 9:31 AM, Daniel Pocock <da...@pocock.pro> wrote:
>
> I notice none of my recent pull requests has been merged. This makes it
> awkward because I don't want my own work to diverge significantly if
> more time passes and I don't want other contributors or users to
> potentially waste time on issues that I have worked on.
>
> I've tried to make each contribution a discrete fix so it is easier to
> review and revise if necessary. However, some of my patches already
> overlap with each other and extra effort may need to be expended
> resolving merge conflicts if the code diverges further.
>
> I looked at the contribution guidelines here:
>
> http://camel.apache.org/contributing.html
>
> and I understand that the old process required patches for bugs to be
> submitted in JIRA
>
> Under the Github heading in that page, it is not clear if every pull
> request must reference a JIRA issue.
>
> For example, the java.sql.Timestamp type converter doesn't fix any bug,
> it is a new feature:
>
> https://github.com/apache/camel/pull/344
>
> so do I still need to open a JIRA issue for that or is the pull request sufficient?
>
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/