I'd like to add some words ... IMO each contributor should be responsible his patch can be applied w/o any problems. That's why he should check these patches and run the tests before filling new JIRA issue. However nobody can guarantee either patch will be successfully applied later due to the possible conflicts. Therefore it'd be not bad to have a reference to the revision number this patch has been created for. I suppose it will lighten the work for committers. Does it make sense?
Thanks, Vladimir. On 9/14/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
Just thought of another item. I've seen a patch recently where a move was encapsulated in the patch. We should encourage contributions to supply recipes/scripts for "svn move" commands rather than non-atomic deletions and additions in patches. -Mark. On 14 September 2006 at 14:29, Mark Hindess <[EMAIL PROTECTED]> wrote: > > On 14 September 2006 at 17:13, "Alexey Petrenko" < [EMAIL PROTECTED] > > wrote: > > Agree on both cases. > > We can also ask to use dos2unix utility on Windows to convert patches > > to unix LF fromat. > > I'm actually less worried about this one. I tend to be able to get any > patch to work under linux using either dos2unix or using: > > perl -pe '/^(Index|====|---|\+\+\+|[EMAIL PROTECTED]@)/&&s/\r//;' > > to remove the CR characters only from the metadata. The latter will > become obsolete when we sort out the eol problems in svn. > > -Mark. > > > SY, Alexey > > > > 2006/9/14, Mark Hindess <[EMAIL PROTECTED]>: > > > > > > I'd suggest two further things. > > > > > > First, we change the default JIRA priority to something lower than > > > 'Major'. Currently most come in as 'Major' even if they are trivial > > > edge cases that might never affect an application. I assume because > > > people are just leaving the default unchanged without giving it much > > > thought. If we change the default, then the guidelines could suggest > > > only raising the priority if the bug affects a real application. > > > > > > Second, can we ask that all patches be relative to either the top-level > > > (where the main build.xml is) or modules/<module-name> (where a modules > > > build.xml is). It bothers me when I see patches with files that > > > start with trunk/modules/... rather than trunk because I worry about > > > just how much these people are checking out. At the other end of the > > > spectrum it takes much longer to apply a JIRA if, for example, I have to > > > change directory to modules/awt/src/test/api/java/common/java/awt/geom > > > to apply the test patch and then change directory > > > modules/awt/src/main/java/common/java/awt/geom to apply the fix. > > > > > > Don't get me wrong though, I'm grateful for all bug reports and patches > > > but if we can make things a little more efficient then perhaps we might > > > get through them more quickly. > > > > > > Regards, > > > Mark. > > > > > > On 14 September 2006 at 11:33, Oliver Deakin < [EMAIL PROTECTED] > m> > > wrote: > > > > Thanks Alexey - I think these guidelines will be helpful for all of > > > > us, whether opening, fixing or committing bugs and patches. > > > > Just a couple of extra comments. > > > > > > > > Alexey Petrenko wrote: > > > > > Guys, > > > > > > > > > > I think that we need to create something like "Good issue resolution > > > > > guideline" and post it on Harmony site or wiki. It will help communit > y > > > > > to prepare good fixes and will help committers to spend less time on > > > > > applying other's patches. > > > > > > > > > > As a start we can take Nathan's post with additions from Paulex. I'll > > > > > add few points from me... > > > > > > > > > > Issue reporter: > > > > > 1. Reporter should try to create as small test case as possible. Patc > h > > > > > to test will be highly appreciated. > > > > > > > > 1a. Provide plenty of information about steps necessary to recreate the > > > > bug. If > > > > a patch for the fix has not been supplied, provide as much diagnostic > > > > information > > > > about the failure as possible (stack trace, failure output, expected > > > > output etc.). > > > > > > > > > 2. Do not forget to use issue links if applicable. > > > > > > > > > > Resolution provider :) : > > > > > 1. Issue is probably a non-bug difference, not a bug or invalid: > > > > > 1.1. Discuss on dev-list. > > > > > 1.2. Add a link to the discussion thread as a comment to issue. > > > > > 2. Issue is a bug: > > > > > 2.1. If reporter did not provide patch to test: > > > > > 2.1.1. If it is possible to create a patch to test then create > i > > t. > > > > > 2.1.2. If it is not possible then note it in the comment. > > > > > 2.2. Create a patch to fix the issue > > > > > 2.2.1. Any concerns? Discuss on dev list. Add a link to > > > > > discussion as a comment. > > > > > > > > We should also add a step here to say "add a comment to the JIRA > > > > indicating that you are working on this bug", as suggested by Geir > > > > at [1]. > > > > > > > > Regards, > > > > Oliver > > > > > > > > [1] > > > > http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.m > bo > > x/%3 > > > > [EMAIL PROTECTED] > > > > > > > > > 3. Do not forget to use issue links if applicable. > > > > > > > > > > Committer > > > > > 1. Issue is probably a non-bug difference, not a bug or invalid: clos > e > > > > > the issue. > > > > > 2. Issue is a bug: > > > > > 2.1. Apply the patch to test if it exists. > > > > > 2.2. Check that test fails. > > > > > 2.3. Apply the fix for the issue > > > > > 2.4. Check that test does not fail any more > > > > > 2.5. If there is a problem on previous steps post a comment to > > > > > JIRA and let "resolution provider" to resolve. > > > > > > > > > > Thoughts? Comments? Additions? > > > > > > > > > > SY, Alexey > > > > > > > > > > 2006/9/13, Paulex Yang <[EMAIL PROTECTED]>: > > > > >> Nathan Beyer wrote: > > > > >> > Here are a few things that I think might help with getting through > > > > >> some of > > > > >> > the older outstanding issues, as well as new ones. > > > > >> > > > > > >> > * If an issue is old (over a month???), then verify that it's stil > l > > > > >> an issue > > > > >> > with the latest code and note this with a JIRA comment. > > > > >> > * Obviously posting patches is great, but patches without tests ar > e > > > > >> almost > > > > >> > always ignored. > > > > >> > ** If you're posting an enhancement, post a patch that enhances th > e > > > > >> tests > > > > >> > and make sure they pass on an RI. (I always make sure the test > > > > >> passes on the > > > > >> > RI before considering the patch.) > > > > >> > ** If you're posting a fix, post a patch that includes a regressio > n > > > > >> test. (I > > > > >> > always apply the test first, then run it to see it fail, then I > > > > >> look at the > > > > >> > fix.) > > > > >> > * If there's a particular JIRA issue that you would like fixed and > > > > >> a patch > > > > >> > already exists, try applying the patch yourself, verify it and the > n > > > > >> add a > > > > >> > comment supporting the patch. > > > > >> > > > > > >> > > > > > >> > -Nathan > > > > >> +1 from me, this is an excellent guide. Only one more thing: > > > > >> > > > > >> * If the JIRA/patch is debatable for any reasons (non-bug difference > , > > > > >> break others, any other concerns...), don't hesitate to forward it t > o > > > > >> dev-list for discussion. > > > > >> > > > > >> And further, if possible, I suggest to look at related JIRAs in one > ru > > n, > > > > >> for example, there may be several issues/patches related to > > > > >> ObjectOutputStream, if you fixed/updated one, another patch may be > > > > >> outdated, a better way is to link them and consider them together. > > > > > > > > > > > > > -- > > > > Oliver Deakin > > > > IBM United Kingdom Limited > > > > > > > > > > > > --------------------------------------------------------------------- > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Alexey A. Petrenko > > Intel Middleware Products Division > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
