Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of alexey.a.petrenko@gmail.com
 designates 74.125.46.156 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=ucG0VPEm1LWdCGxxjbFjj1PYPHCBq8PyQ45AcQDZorH+WNuJ7i4hhVXVKdN+FnVtZUBpAX81mp6RDxyYJTvHqyjfNF9U+/BbE6oymBL3BI4A/G653rsdomd2vVoMdsHs9PaPCjFB3Sl1qJedfDahURyeVedaMMlI46/FTR6d/Yk=
Message-ID: <c3755b3a0804290446v776f0dbdlc08af09bce926641@mail.gmail.com>
Date: Tue, 29 Apr 2008 15:46:56 +0400
From: "Alexey Petrenko" <alexey.a.petrenko@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [general] How to be a good contributor?
In-Reply-To: <3b3f27c60804241738o32228389j3494a17cd0dde293@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4bebff790804240834s4f9b0560yfac515066702e7c9@mail.gmail.com>
	 <3b3f27c60804241738o32228389j3494a17cd0dde293@mail.gmail.com>

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