You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Reuben Garrett <re...@gmail.com> on 2012/03/09 17:25:17 UTC

patching process for ultra-fine revisions

What's our normal process for submitting patches against very small
sections of the code base (e.g. one-word javadoc corrections)?  For
example, I noticed that the default timeout value for iPOJO's @Temporal
annotation [1] is javadoc'd as "true", but is actually a long with default
3000.

It seems like overkill to open a JIRA ticket for that, although maybe it's
not a big deal if we're not worried about exhausting the ticket number
namespace.  One could also group together several such changes, although
this raises the question of how many changes are sufficient, and delays
corrections until that threshold is reached.

Sorry if I'm over-thinking this - I'm still a fledgling.

~ RNPG

[1] :
http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.ipojo.annotations-1.8.0/src/main/java/org/apache/felix/ipojo/handler/temporal/Temporal.java

Re: patching process for ultra-fine revisions

Posted by "Richard S. Hall" <he...@ungoverned.org>.
We don't. Everything happens in our svn repo and/or as patches attached 
to JIRA issues.

-> richard

On 3/10/12 6:20, Benedikt Ritter wrote:
> The source is also available at github [1]. I know that commons lang
> allows pull requests at github. How do you handle the git repository
> and it's mirror at github?
> Github makes contributing and reviewing easy (after you have
> understood the git concept of source control [and that can take a
> while ;) ])
> Nevertheless, I agree that having everything documented at JIRA is a good thing.
>
> Regards,
> Benedikt
>
>
> [1] https://github.com/apache/felix
>
> Am 9. März 2012 18:16 schrieb Reuben Garrett<re...@gmail.com>:
>> i made a patch to practice.  i'm not sure if JIRA has an indicator for
>> "patch attached" or if it's hidden by my karma, not that it matters for
>> this case.
>>
>> with time, i hope to bring more significant contributions.  all the same,
>> thanks for your time and guidance!
>>
>> https://issues.apache.org/jira/browse/FELIX-3380
>>
>> ~ RNPG

Re: patching process for ultra-fine revisions

Posted by Benedikt Ritter <be...@googlemail.com>.
The source is also available at github [1]. I know that commons lang
allows pull requests at github. How do you handle the git repository
and it's mirror at github?
Github makes contributing and reviewing easy (after you have
understood the git concept of source control [and that can take a
while ;) ])
Nevertheless, I agree that having everything documented at JIRA is a good thing.

Regards,
Benedikt


[1] https://github.com/apache/felix

Am 9. März 2012 18:16 schrieb Reuben Garrett <re...@gmail.com>:
> i made a patch to practice.  i'm not sure if JIRA has an indicator for
> "patch attached" or if it's hidden by my karma, not that it matters for
> this case.
>
> with time, i hope to bring more significant contributions.  all the same,
> thanks for your time and guidance!
>
> https://issues.apache.org/jira/browse/FELIX-3380
>
> ~ RNPG

Re: patching process for ultra-fine revisions

Posted by Reuben Garrett <re...@gmail.com>.
i made a patch to practice.  i'm not sure if JIRA has an indicator for
"patch attached" or if it's hidden by my karma, not that it matters for
this case.

with time, i hope to bring more significant contributions.  all the same,
thanks for your time and guidance!

https://issues.apache.org/jira/browse/FELIX-3380

~ RNPG

Re: patching process for ultra-fine revisions

Posted by "Richard S. Hall" <he...@ungoverned.org>.
p.s. I should add, it is not necessary to provide a real patch for 
really simple cases, if you can precisely describe it in the 
description...patches are just nice because they remove all doubt.

On 3/9/12 11:25 , Reuben Garrett wrote:
> What's our normal process for submitting patches against very small
> sections of the code base (e.g. one-word javadoc corrections)?  For
> example, I noticed that the default timeout value for iPOJO's @Temporal
> annotation [1] is javadoc'd as "true", but is actually a long with default
> 3000.
>
> It seems like overkill to open a JIRA ticket for that, although maybe it's
> not a big deal if we're not worried about exhausting the ticket number
> namespace.  One could also group together several such changes, although
> this raises the question of how many changes are sufficient, and delays
> corrections until that threshold is reached.
>
> Sorry if I'm over-thinking this - I'm still a fledgling.
>
> ~ RNPG
>
> [1] :
> http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.ipojo.annotations-1.8.0/src/main/java/org/apache/felix/ipojo/handler/temporal/Temporal.java
>

Re: patching process for ultra-fine revisions

Posted by "Richard S. Hall" <he...@ungoverned.org>.
You're over thinking it. :-)

Opening an issue is probably the best way, since it enables a single 
work pattern for making sure things don't get lost. Don't worry about 
conserving bits.

Besides, we feel really productive when we can resolve open issues... ;-)

-> richard

On 3/9/12 11:25 , Reuben Garrett wrote:
> What's our normal process for submitting patches against very small
> sections of the code base (e.g. one-word javadoc corrections)?  For
> example, I noticed that the default timeout value for iPOJO's @Temporal
> annotation [1] is javadoc'd as "true", but is actually a long with default
> 3000.
>
> It seems like overkill to open a JIRA ticket for that, although maybe it's
> not a big deal if we're not worried about exhausting the ticket number
> namespace.  One could also group together several such changes, although
> this raises the question of how many changes are sufficient, and delays
> corrections until that threshold is reached.
>
> Sorry if I'm over-thinking this - I'm still a fledgling.
>
> ~ RNPG
>
> [1] :
> http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.ipojo.annotations-1.8.0/src/main/java/org/apache/felix/ipojo/handler/temporal/Temporal.java
>

Re: patching process for ultra-fine revisions

Posted by Felix Meschberger <fm...@adobe.com>.
Hi,

Am 09.03.2012 um 08:25 schrieb Reuben Garrett:

> What's our normal process for submitting patches against very small
> sections of the code base (e.g. one-word javadoc corrections)?  For
> example, I noticed that the default timeout value for iPOJO's @Temporal
> annotation [1] is javadoc'd as "true", but is actually a long with default
> 3000.
> 
> It seems like overkill to open a JIRA ticket for that, although maybe it's
> not a big deal if we're not worried about exhausting the ticket number
> namespace.  One could also group together several such changes, although
> this raises the question of how many changes are sufficient, and delays
> corrections until that threshold is reached.

IMHO the cleanest thing is to go with JIRA issues. Don't care about running out of ticket numbers ...

The only point is that it looks like somewhat heavy lifting. Yet, you will have issue backed traces of the code changes...

Regards
Felix