harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [general] How to be a good contributor?
Date Thu, 24 Apr 2008 16:18:41 GMT
Hello Aleksey,

1. First, following conventions does not mean your patches won't be
criticized. If you know conventions, you get "citation" arguments to
defend your patches against critics.

2. I use Eclipse standard conventions for Java with tabs replaced with spaces.

3. I consider patch separation as poorly defined process. I recall a
recent conversation:
- Do you want me to separate another three patches from my big patch?
- Thanks, this won't be of much help anyway.

I think the main thing here is in the head of the patch author. He
should plan his work in advance as series of subsequent conventional

4. I believe that's ok to attach partial patches if you
        don't set "patch available" flag,
        licensed to Apache,
        and clearly define expectations from this patch.


On Thu, Apr 24, 2008 at 7:34 PM, Aleksey Shipilev
<aleksey.shipilev@gmail.com> wrote:
> Hi Alexey (Petrenko), Nathan, Mark, all!
>  Thanks for supporting me in creating the good patches against Harmony!
>  I had read "Good Issue Resolution Guideline" [1] and "Bad Smells" [2].
>  I will struggle to comply with them further. But also I need to know
>  the answers on topics which are not covered by the docs. I have my own
>  answers on them, but it would be great to see if my perception is what
>  Harmony committers expect.
>   1. Coding conventions. What coding convention Harmony is using? Is it
>  common "Code Conventions for the Java" [3]?
>   2. Patch separation. I see that there is an requirement in place to
>  divide test and implementation parts into distinct patches. Does that
>  apply to formatting, documentation and
>  text-reordering patches? I guess, it does.
>   3. Explaining what the patch does. To what extent should one describe
>  what exactly the patch does: should it be the "investigation path"
>  which lead to fix, short description of fundamental changes, the
>  reason why this exact solution is better? I think that short
>  description on each change in patch should be enough.
>   4. Proof-of-concept patches. Is it acceptable to have POC patches
>  attached to JIRA if there's distinct reminder that the patch is
>  prototype and is not supposed to be committed? Personally I like to
>  attach the "checkpoint patches" to JIRA when I'm working on issues,
>  'cause this could minimize the efforts on continuing works in case of
>  something happens with my computer or me :)
>  I think the answers on these questions worth publishing in resolution
>  guideline or similar document.
>  Is there anything else to read about good coding practices?
>  Thanks!
>  Aleksey.
>  [1] http://harmony.apache.org/issue_resolution_guideline.html
>  [2] http://sis36.berkeley.edu/projects/streek/agile/bad-smells-in-code.html
>  [3] http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

With best regards,

View raw message