Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (idunn.apache.osuosl.org: domain gmail.com designates
 66.249.82.224 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=gKTrLugQk0papeLXMaBt9vEkzBtyxlKiP5bme9P69Y+IHGIdFW66fH6VCPWHwkiit/dpTeeFe8L1TZL9Msqy2LFuJtcKC8z9Q9aAEI4QrB/vDCgjAZxsSNKw8uR80QiXjzERZWixm8kHXphbF6qI0RJ7NvWdsDLvTq073fVGWa4=
Message-ID: <c3755b3a0609210349l7af75bfv9b7a2e98ba7a8ec5@mail.gmail.com>
Date: Thu, 21 Sep 2006 14:49:24 +0400
From: "Alexey Petrenko" <alexey.a.petrenko@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer
 to supply patches for old JIRAs)
In-Reply-To: <2c9597b90609210337wfbef550ld912d6ad795c87ae@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <c3755b3a0609130707j775c942fl933d92154cdab226@mail.gmail.com>
	 <450A9100.8030907@pobox.com>
	 <c3755b3a0609192344j7938f46cq42fb23c7bad41c24@mail.gmail.com>
	 <26c14c2a0609200253w757d1aaei599024051647eb73@mail.gmail.com>
	 <c3755b3a0609200256m4f3556ccjf6f90f4c5792d9f1@mail.gmail.com>
	 <200609201013.k8KADbff022892@d06av02.portsmouth.uk.ibm.com>
	 <c3755b3a0609200448q3592ab06q64d44737d8f56e90@mail.gmail.com>
	 <200609201202.k8KC29gv030547@d06av02.portsmouth.uk.ibm.com>
	 <c3755b3a0609200514p261ddfbevfb9e6b9b1330fd08@mail.gmail.com>
	 <2c9597b90609210337wfbef550ld912d6ad795c87ae@mail.gmail.com>

Good point! Thanks.

2006/9/21, Alexei Zakharov <alexei.zakharov@gmail.com>:
> Hi Alexey,
>
> IMHO it would be nice to explicitly state (for issue reports and/or
> resolution providers) that patch to classlib code and patch to test
> should be two separate patches. I personally posted several "combined"
> patches in the past. :)
>
> Regards,
>
> 2006/9/20, Alexey Petrenko <alexey.a.petrenko@gmail.com>:
> > 2006/9/20, Mark Hindess <mark.hindess@googlemail.com>:
> > >
> > > Alexey,
> > >
> > > What was wrong with the initial suggestion of recommending patches
> > > be either relative to the classlib/trunk or
> > > classlib/trunk/module/<module-name>?
> > Seems I was not very attentive...
> > "Harmony root or module root" looks fine.
> >
> > Any other objections or corrections?
> >
> > SY, Alexey
> >
> > > I really don't care much *except* that there were two specific types
> > > of patches I was trying to avoid as I mentioned when I first suggested
> > > this guideline.  So I definitely think a guideline of some form would be
> > > constructive.
> > >
> > > Regards,
> > >  Mark.
> > >
> > > On 20 September 2006 at 15:48, "Alexey Petrenko" <alexey.a.petrenko@gmail.com> wrote:
> > > > Then we should remove this requirement at all...
> > > > Since it is possible to have a patches for a few modules at once. Or
> > > > for a few modules and a doc.
> > > >
> > > > 2006/9/20, Mark Hindess <mark.hindess@googlemail.com>:
> > > > >
> > > > > On 20 September 2006 at 13:56, "Alexey Petrenko" <alexey.a.petrenko@gmail.c
> > > > om> wrote:
> > > > > > Not module build.xml but the main build.xml.
> > > > > > Anyway since we got a lot of directories except of modules it is
> > > > > > better to make a diff from the root.
> > > > >
> > > > > I anticipate that in time we will have people that only check out the
> > > > > module they wish to work on.  So I'm happy to see patches relative to
> > > > > a module's build.xml directory.
> > > > >
> > > > > -Mark.
> > > > >
> > > > >
> > > > > > 2006/9/20, Oleg Khaschansky <oleg.v.khaschansky@gmail.com>:
> > > > > > > 2.4. All the pacthes (test and fix) should be relative to the
> > > > > > > directory where the main build.xml is:
> > > > > > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
> > > > unk
> > > > > > >
> > > > > > > As Mark noted, the directory where the module's build.xml is located
> > > > > > > is also acceptable.
> > > > > > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
> > > > unk/
> > > > > > modules/module_name
> > > > > > > Generally, making the patch from this directory is much faster then
> > > > > > > from the classlib/trunk :)
> > > > > > >
> > > > > > >
> > > > > > > On 9/20/06, Alexey Petrenko <alexey.a.petrenko@gmail.com> wrote:
> > > > > > > > I've combined all the ideas. And here is the result.
> > > > > > > >
> > > > > > > > === cut ===
> > > > > > > > Preface
> > > > > > > > This guideline covers a wide range of issues but not all of them.
> > > > > > > > If you cannot do one of the steps, then write a comment to the issue.
> > > > > > > > Use your common sense!
> > > > > > > >
> > > > > > > > Issue reporter:
> > > > > > > > 1. Explicitly state the expected behavior and the
> > > > > > > > actual behavior of Harmony code. Use links to specs, rfcs, etc.
> > > > > > > > 2. Try to create as small a test case as possible. A patch
> > > > > > > > to test will be highly appreciated.
> > > > > > > > 3. Provide max. information about steps necessary to recreate the bug
> > > > .
> > > > > > > > If a patch for the test has not been supplied, provide as much
> > > > > > > > diagnostic information about the failure as possible (stack trace,
> > > > > > > > failure output, expected output etc).
> > > > > > > > 4. Remember to use issue links if applicable.
> > > > > > > > 5. Check the issue resolution when it is committed. Add a comment.
> > > > > > > >
> > > > > > > > Resolution provider :) :
> > > > > > > > Depending on the type of issue, do the following:
> > > > > > > > 1. Issue is probably a non-bug difference, not a bug or invalid:
> > > > > > > >    1.1. Discuss on the dev list.
> > > > > > > >    1.2. Add a link to the discussion thread as a comment to issue.
> > > > > > > > 2. Issue is a bug:
> > > > > > > >    2.1. Notify the community that you started investigation by adding
> > > > > > > > a comment to the issue. If you cannot produce a patch, add another
> > > > > > > > comment with the results of your investigation.
> > > > > > > >    2.2. If reporter did not provide a patch to test:
> > > > > > > >        2.2.1. Try to create a patch to test.
> > > > > > > >        2.2.2. If you cannot produce a patch, write a comment about it
> > > > .
> > > > > > > >    2.3. Create a patch to fix the issue
> > > > > > > >        2.3.1. Any concerns? Discuss on the dev list. Add a link to
> > > > > > > > discussion as a comment.
> > > > > > > >    2.4. All the pacthes (test and fix) should be relative to the
> > > > > > > > directory where the main build.xml is:
> > > > > > > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/
> > > > trun
> > > > > > k
> > > > > > > >    2.5. If the patch requires to add, remove or move some files in th
> > > > e
> > > > > > > > repository, add the appropriate script.
> > > > > > > >    2.6. Check that all unit tests pass.
> > > > > > > >    2.7. If it is an application-oriented issue, check the application
> > > > .
> > > > > > > >    2.8. Remember to use issue links if applicable.
> > > > > > > >
> > > > > > > > Committer:
> > > > > > > > Depending on the issue type, do:
> > > > > > > > 1. Issue is a non-bug difference, not a bug or invalid:
> > > > > > > > Close the issue.
> > > > > > > > 2. Issue is a bug:
> > > > > > > >    2.1. If a patch to test is available, apply it.
> > > > > > > >    2.2. Check that the test fails.
> > > > > > > >    2.3. Apply the fix for the issue.
> > > > > > > >    2.4. Check that test succeeds now.
> > > > > > > >    2.5. Make sure that all unit tests pass.
> > > > > > > >    2.6. For application-oriented issues, check the application.
> > > > > > > >    2.7. If there are problems on previous steps, post a comment to
> > > > > > > > JIRA and let "resolution provider" to resolve.
> > > > > > > >    2.8. Make sure that the issue reporter is happy with the resolutio
> > > > n.
> > > > > > > >    2.9. Add revision info into JIRA issue
> > > > > > > >
>
>
> --
> Alexei Zakharov,
> Intel Middleware Product Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Alexey A. Petrenko
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org