harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Petrenko" <alexey.a.petre...@gmail.com>
Subject Re: [general] How to be a good contributor?
Date Tue, 29 Apr 2008 11:46:56 GMT
2008/4/25 Nathan Beyer <ndbeyer@apache.org>:
> On Thu, Apr 24, 2008 at 10:34 AM, 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]?
> Yes and no. For the most part, these cover the basic formatting style used.
> On the other hand, always respect the format that has already been
> established, unless is ridiculously out of whack.
> >
> >
> >  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.
> >
> I think there are various approaches and everyone has a slightly different
> preference. I like fewer patches, but that's general because I prefer very
> targeted changes, which generally aren't large. For bugs, it's nice to have
> a test patch that can be applied and show the failure, which is separate
> from the fix patch.
> >
> >  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.
> Bugs - describe the bug, why it's a bug and how the bug is fixed
> Enhancement - describe what it is, describe the value (don't assume it's
> self-evident)
> >
> >
> >  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 :)
> Personally, I don't think POC work should be put into JIRA, at least not in
> general. This is just normal development and it should be brought up in the
> mailing list. A POC, in essence is just an idea that's illustrated with
> code. Ideas have to be discussed and communicated before they can make it
> into the code base and the only place to do that is the mailing list.
I agree with you. But I do not see any issue with creating JIRA,
describing the issue, and adding POC there.
It should be properly marked and discussed in dev list of course.

SY, Alexey

View raw message