2008/4/25 Nathan Beyer <[EMAIL PROTECTED]>: > On Thu, Apr 24, 2008 at 10:34 AM, Aleksey Shipilev < > [EMAIL PROTECTED]> 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
