RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Nadya, all, I've created JIRA issue and attached a patch to remove this extra table. See https://issues.apache.org/jira/browse/HARMONY-2140 I've checked several pages, nothing seems to be broken. Please review the changes. Regards, -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 10:56 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Alexey, I agree that the structure of the resulting HTML website page does not appear too linear. When editing the structure, I saw the additional table - and left as is; maybe, because I hoped somebody added it on some purpose. For me, the only matter of convenience is that all content that is varied on the page is in a separate table. If nobody has an idea why the structure is so complex, we can simplify it. The structure is defined in file site.vsl in site/xdocs/stylesheets. A JIRA with patch is welcome as usual. Thank you, Nadya Morozova -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 5:20 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Sveta, all, I've attached the updated patch to the JIRA. Please review. Regards, Alexey. P.S. By the way, do we really need to place all the main content into another table? I've just looked at the source of the generated HTML file, and found it quite confusing. I agree to have a table to format the heading of the page and the list of contents on the left, but why there's another table where the main content is. I am about this one: /ul !-- end of the list of contents -- /td !-- end of list of contents cell -- td width=80% valign=topa name=top/a !-- the main content goes in this cell -- table cellspacing=0 cellpadding=2 width=100% !-- why is this table here -- trtd h1 a name=Good Issue Resolution GuidelineGood Issue Resolution Guideline/a /h1 /td/tr trtd... !-- and so on -- The comments here are added by me, and the source is slightly reformatted. I believe, the body part of the XML can be placed almost as is in the content cell of the top-level table without the need for another table because it's useless here. Or is it just Anakia limitation? -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 3:50 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Alexey, I'd change the heading Reporting the Issue to Reporting an Issue, or omit article at all. Well, both articles seem to be fine. Let it be a/an Maybe just omit articles then? Well, how about the third variant: Reporting Issues? I'm still for 'reproduce' because a bug can be (non-)reproducible but not recreatable. Any other opinions? Ok, reproduce is fine I'd say: If you have any questions, discuss them... That's even better :) Cool!:) All patches, such as tests and fixes, should be Good! It's clearer. Fine! OK. I'll prepare patch update then. Good luck! I'd be glad to review it, if you do not mind. :) Cheers, Sveta Thanks, Alexey. Best regards, Sveta -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 1:33 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:01 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've just submitted a new JIRA [http://issues.apache.org/jira/browse/HARMONY-2110]. I've added the necessary links from the website to the new page and have tried to perfect it a little. It would be great, if you could find a chance to look through the patch. Thanks in advance. Sveta, I've taken a look and added my comments to the JIRA itself. Regards, Alexey. Best regards, Sveta -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 11:18 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Good! Go ahead. Do you need help? I can review the patch - just let me know when you submit the JIRA. Thank you, Nadya Morozova -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday,
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
-Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 10:37 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Alexey, Thanks for the patch. I've looked it through and have fixed certain issues. The new patch is created (Harmony-2110). It'd be great, if you could find a chance to review it. Everything's fine. It's time to update the site then :) Regards, Alexey. Best regards, Sveta -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 5:20 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Sveta, all, I've attached the updated patch to the JIRA. Please review. Regards, Alexey. P.S. By the way, do we really need to place all the main content into another table? I've just looked at the source of the generated HTML file, and found it quite confusing. I agree to have a table to format the heading of the page and the list of contents on the left, but why there's another table where the main content is. I am about this one: /ul !-- end of the list of contents -- /td !-- end of list of contents cell -- td width=80% valign=topa name=top/a !-- the main content goes in this cell -- table cellspacing=0 cellpadding=2 width=100% !-- why is this table here -- trtd h1 a name=Good Issue Resolution GuidelineGood Issue Resolution Guideline/a /h1 /td/tr trtd... !-- and so on -- The comments here are added by me, and the source is slightly reformatted. I believe, the body part of the XML can be placed almost as is in the content cell of the top-level table without the need for another table because it's useless here. Or is it just Anakia limitation? -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 3:50 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Alexey, I'd change the heading Reporting the Issue to Reporting an Issue, or omit article at all. Well, both articles seem to be fine. Let it be a/an Maybe just omit articles then? Well, how about the third variant: Reporting Issues? I'm still for 'reproduce' because a bug can be (non-)reproducible but not recreatable. Any other opinions? Ok, reproduce is fine I'd say: If you have any questions, discuss them... That's even better :) Cool!:) All patches, such as tests and fixes, should be Good! It's clearer. Fine! OK. I'll prepare patch update then. Good luck! I'd be glad to review it, if you do not mind. :) Cheers, Sveta Thanks, Alexey. Best regards, Sveta -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 1:33 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:01 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've just submitted a new JIRA [http://issues.apache.org/jira/browse/HARMONY-2110]. I've added the necessary links from the website to the new page and have tried to perfect it a little. It would be great, if you could find a chance to look through the patch. Thanks in advance. Sveta, I've taken a look and added my comments to the JIRA itself. Regards, Alexey. Best regards, Sveta -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 11:18 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Good! Go ahead. Do you need help? I can review the patch - just let me know when you submit the JIRA. Thank you, Nadya Morozova -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 9:13 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya wrote: Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html +1 it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. If you do not mind, I can create the necessary patches. Best regards, Sveta Konovalova -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexey, I've applied your patch and must admit that my local site looks much better now. It really breaks nothing! :) The patch makes a white space between the end of a section and a title of the next one wider. IMHO it enhances information perception and makes pages more comprehensible. +1 for the patch Best regards, Sveta -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 11:18 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya, all, I've created JIRA issue and attached a patch to remove this extra table. See https://issues.apache.org/jira/browse/HARMONY-2140 I've checked several pages, nothing seems to be broken. Please review the changes. Regards, -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 10:56 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Alexey, I agree that the structure of the resulting HTML website page does not appear too linear. When editing the structure, I saw the additional table - and left as is; maybe, because I hoped somebody added it on some purpose. For me, the only matter of convenience is that all content that is varied on the page is in a separate table. If nobody has an idea why the structure is so complex, we can simplify it. The structure is defined in file site.vsl in site/xdocs/stylesheets. A JIRA with patch is welcome as usual. Thank you, Nadya Morozova -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 5:20 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Sveta, all, I've attached the updated patch to the JIRA. Please review. Regards, Alexey. P.S. By the way, do we really need to place all the main content into another table? I've just looked at the source of the generated HTML file, and found it quite confusing. I agree to have a table to format the heading of the page and the list of contents on the left, but why there's another table where the main content is. I am about this one: /ul !-- end of the list of contents -- /td !-- end of list of contents cell -- td width=80% valign=topa name=top/a !-- the main content goes in this cell -- table cellspacing=0 cellpadding=2 width=100% !-- why is this table here -- trtd h1 a name=Good Issue Resolution GuidelineGood Issue Resolution Guideline/a /h1 /td/tr trtd... !-- and so on -- The comments here are added by me, and the source is slightly reformatted. I believe, the body part of the XML can be placed almost as is in the content cell of the top-level table without the need for another table because it's useless here. Or is it just Anakia limitation? -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 3:50 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Alexey, I'd change the heading Reporting the Issue to Reporting an Issue, or omit article at all. Well, both articles seem to be fine. Let it be a/an Maybe just omit articles then? Well, how about the third variant: Reporting Issues? I'm still for 'reproduce' because a bug can be (non-)reproducible but not recreatable. Any other opinions? Ok, reproduce is fine I'd say: If you have any questions, discuss them... That's even better :) Cool!:) All patches, such as tests and fixes, should be Good! It's clearer. Fine! OK. I'll prepare patch update then. Good luck! I'd be glad to review it, if you do not mind. :) Cheers, Sveta Thanks, Alexey. Best regards, Sveta -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 1:33 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:01 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've just submitted a new JIRA [http://issues.apache.org/jira/browse/HARMONY-2110]. I've added the necessary links from the website to the new page and have tried to perfect it a little. It would be great, if you could find a chance to look through the patch. Thanks in advance. Sveta, I've taken
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
-Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:01 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've just submitted a new JIRA [http://issues.apache.org/jira/browse/HARMONY-2110]. I've added the necessary links from the website to the new page and have tried to perfect it a little. It would be great, if you could find a chance to look through the patch. Thanks in advance. Sveta, I've taken a look and added my comments to the JIRA itself. Regards, Alexey. Best regards, Sveta -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 11:18 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Good! Go ahead. Do you need help? I can review the patch - just let me know when you submit the JIRA. Thank you, Nadya Morozova -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 9:13 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya wrote: Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html +1 it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. If you do not mind, I can create the necessary patches. Best regards, Sveta Konovalova -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 8:24 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Well, I guess the simplest solution would be to add the link to the Conventions section on the front page of wiki. You can do it yourself! Adding a link from the static website would also be useful. Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 4:44 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya, we definetly need a link to this page. That's not a question. Question is where to place the link. And as I said in previous email link place suggestions are welcome. SY, Alexey 2006/11/7, Morozova, Nadezhda [EMAIL PROTECTED]: Alexey, Would be great if there we some page that had a link to the page; otherwise, you cannot find it from within wiki, only from the link in your mail :( Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 1:32 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've published Good issue resolution guideline on Harmony site: http://incubator.apache.org/harmony/issue_resolution_guideline.html (wait for a while for the web site synchronization). It is not linked to other pages yet. So comments to guideline and link place suggestions are welcome. SY, Alexey SNIP -- Alexey A. Ivanov Intel Enterprise Solutions Software Division
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexey, Thank you so much for providing such a detailed review. I'd change the heading Reporting the Issue to Reporting an Issue, or omit article at all. Well, both articles seem to be fine. Let it be a/an Create as small test case, as possible sounds not very good. (The comma shouldn't be used here any way.) I think Create a test case as small as possible is better. What do you think? +1 The next item: ...about the steps to *reproduce* the bug. Using 'reproduce' is more conventional than 'recreate' in this case. Let it be recreate And again extra comma: ...information about the failure, as possible: stack trace. You should remove it. Consider using bulleted list for enumeration here, I mean stack trace, failure output... might be marked up as list, how about it? Sorry, my fault, I've overlooked it. The comma shouldn't be there. IMHO we shouldn't use bulleted list in this case, since we do not publish the complete list of necessary diagnostic information, but just provide three examples. Suggest to leave it as it is. Another point is lists can't be part of paragraph in HTML, thus you should remove the opening and closing tags of paragraph in the subsection. I mean: +subsection name=Reporting the Issue - p // remove it from file +ol ... /ol -p // remove it from file +/subsection +1, let's fix subsection Resolving *an* Issue. The first paragraph says To close *an* issue, define its type first. We're on stage of resolving here yet, so it should be To resolve an issue... Good catch! There's no ending punctuation in the list If reporter did not provide a patch to test:. Thanks! Should be fixed. Following, I'd re-write sentence like this: If you have any concerns, discuss *them* (was: questions) on the I'd say: If you have any questions, discuss them... IMHO, there are extra articles which should be omitted, however, I'm not a native speaker... Sorry, I'm not with you here. IMHO they are used appropriately. subsection Closing *an* Issue. The first paragraph says we should define issue type first. I think the type is defined at the stage of resolving, thus it's better to use another word rather than 'define'. But nothing comes to mind at the moment. IMHO it's ok to say define. Before closing the issue, the one should know its type to choose the right way to deal with it, right? I'd leave it as it is. IIRC, non-bug difference issues are not closed. They are left open, to remind of the difference. Am I mistaken? Well, I'm not sure, really...you might know better... Oh, I've missed another place: All _pacthes_, test, and fix should be... Here the word *patch* is misspelled. To my mind, 'test and fix' explain which patches are meant, so this should be surrounded with commas, or even dashes (parentheses may be used as well). This change will make the sentence clearer: All patches - test and fix - should be... I'd better say: All patches, such as tests and fixes, should be I can create another patch which will incorporate my comments, if you like. Go ahead, if you want to. Otherwise, I'll be glad to finalize it. Please let me know if you need my help. Best regards, Sveta -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 1:33 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:01 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've just submitted a new JIRA [http://issues.apache.org/jira/browse/HARMONY-2110]. I've added the necessary links from the website to the new page and have tried to perfect it a little. It would be great, if you could find a chance to look through the patch. Thanks in advance. Sveta, I've taken a look and added my comments to the JIRA itself. Regards, Alexey. Best regards, Sveta -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 11:18 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Good! Go ahead. Do you need help? I can review the patch - just let me know when you submit the JIRA. Thank you, Nadya Morozova -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 9:13 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya wrote: Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html +1 it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful.
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
-Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 2:33 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Alexey, Thank you so much for providing such a detailed review. I'd change the heading Reporting the Issue to Reporting an Issue, or omit article at all. Well, both articles seem to be fine. Let it be a/an Maybe just omit articles then? Create as small test case, as possible sounds not very good. (The comma shouldn't be used here any way.) I think Create a test case as small as possible is better. What do you think? +1 The next item: ...about the steps to *reproduce* the bug. Using 'reproduce' is more conventional than 'recreate' in this case. Let it be recreate I'm still for 'reproduce' because a bug can be (non-)reproducible but not recreatable. Any other opinions? And again extra comma: ...information about the failure, as possible: stack trace. You should remove it. Consider using bulleted list for enumeration here, I mean stack trace, failure output... might be marked up as list, how about it? Sorry, my fault, I've overlooked it. The comma shouldn't be there. IMHO we shouldn't use bulleted list in this case, since we do not publish the complete list of necessary diagnostic information, but just provide three examples. Suggest to leave it as it is. Yep, agree. Another point is lists can't be part of paragraph in HTML, thus you should remove the opening and closing tags of paragraph in the subsection. I mean: +subsection name=Reporting the Issue - p // remove it from file +ol ... /ol -p // remove it from file +/subsection +1, let's fix subsection Resolving *an* Issue. The first paragraph says To close *an* issue, define its type first. We're on stage of resolving here yet, so it should be To resolve an issue... Good catch! There's no ending punctuation in the list If reporter did not provide a patch to test:. Thanks! Should be fixed. Following, I'd re-write sentence like this: If you have any concerns, discuss *them* (was: questions) on the I'd say: If you have any questions, discuss them... That's even better :) IMHO, there are extra articles which should be omitted, however, I'm not a native speaker... Sorry, I'm not with you here. IMHO they are used appropriately. I won't insist on changing this. It's just my impression. subsection Closing *an* Issue. The first paragraph says we should define issue type first. I think the type is defined at the stage of resolving, thus it's better to use another word rather than 'define'. But nothing comes to mind at the moment. IMHO it's ok to say define. Before closing the issue, the one should know its type to choose the right way to deal with it, right? I'd leave it as it is. IIRC, non-bug difference issues are not closed. They are left open, to remind of the difference. Am I mistaken? Well, I'm not sure, really...you might know better... Oh, I've missed another place: All _pacthes_, test, and fix should be... Here the word *patch* is misspelled. To my mind, 'test and fix' explain which patches are meant, so this should be surrounded with commas, or even dashes (parentheses may be used as well). This change will make the sentence clearer: All patches - test and fix - should be... I'd better say: All patches, such as tests and fixes, should be Good! It's clearer. I can create another patch which will incorporate my comments, if you like. Go ahead, if you want to. Otherwise, I'll be glad to finalize it. Please let me know if you need my help. OK. I'll prepare patch update then. Thanks, Alexey. Best regards, Sveta -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 1:33 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:01 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've just submitted a new JIRA [http://issues.apache.org/jira/browse/HARMONY-2110]. I've added the necessary links from the website to the new page and have tried to perfect it a little. It would be great, if you could find a chance to look through the patch. Thanks in advance. Sveta, I've taken a look and added my comments to the JIRA itself. Regards, Alexey. Best regards, Sveta -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 11:18 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Good! Go ahead. Do you need help? I can review the patch -
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexey, I'd change the heading Reporting the Issue to Reporting an Issue, or omit article at all. Well, both articles seem to be fine. Let it be a/an Maybe just omit articles then? Well, how about the third variant: Reporting Issues? I'm still for 'reproduce' because a bug can be (non-)reproducible but not recreatable. Any other opinions? Ok, reproduce is fine I'd say: If you have any questions, discuss them... That's even better :) Cool!:) All patches, such as tests and fixes, should be Good! It's clearer. Fine! OK. I'll prepare patch update then. Good luck! I'd be glad to review it, if you do not mind. :) Cheers, Sveta Thanks, Alexey. Best regards, Sveta -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 1:33 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:01 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've just submitted a new JIRA [http://issues.apache.org/jira/browse/HARMONY-2110]. I've added the necessary links from the website to the new page and have tried to perfect it a little. It would be great, if you could find a chance to look through the patch. Thanks in advance. Sveta, I've taken a look and added my comments to the JIRA itself. Regards, Alexey. Best regards, Sveta -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 11:18 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Good! Go ahead. Do you need help? I can review the patch - just let me know when you submit the JIRA. Thank you, Nadya Morozova -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 9:13 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya wrote: Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html +1 it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. If you do not mind, I can create the necessary patches. Best regards, Sveta Konovalova -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 8:24 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Well, I guess the simplest solution would be to add the link to the Conventions section on the front page of wiki. You can do it yourself! Adding a link from the static website would also be useful. Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 4:44 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya, we definetly need a link to this page. That's not a question. Question is where to place the link. And as I said in previous email link place suggestions are welcome. SY, Alexey 2006/11/7, Morozova, Nadezhda [EMAIL PROTECTED]: Alexey, Would be great if there we some page that had a link to the page; otherwise, you cannot find it from within wiki, only from the link in your mail :( Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 1:32 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've published Good issue resolution guideline on Harmony site: http://incubator.apache.org/harmony/issue_resolution_guideline.html (wait for a while for the web site synchronization). It is not linked to other pages yet. So comments to guideline and link place suggestions are welcome. SY, Alexey SNIP -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -- Alexey A. Ivanov Intel Enterprise Solutions Software Division
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Sveta, all, I've attached the updated patch to the JIRA. Please review. Regards, Alexey. P.S. By the way, do we really need to place all the main content into another table? I've just looked at the source of the generated HTML file, and found it quite confusing. I agree to have a table to format the heading of the page and the list of contents on the left, but why there's another table where the main content is. I am about this one: /ul !-- end of the list of contents -- /td !-- end of list of contents cell -- td width=80% valign=topa name=top/a !-- the main content goes in this cell -- table cellspacing=0 cellpadding=2 width=100% !-- why is this table here -- trtd h1 a name=Good Issue Resolution GuidelineGood Issue Resolution Guideline/a /h1 /td/tr trtd... !-- and so on -- The comments here are added by me, and the source is slightly reformatted. I believe, the body part of the XML can be placed almost as is in the content cell of the top-level table without the need for another table because it's useless here. Or is it just Anakia limitation? -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 3:50 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Alexey, I'd change the heading Reporting the Issue to Reporting an Issue, or omit article at all. Well, both articles seem to be fine. Let it be a/an Maybe just omit articles then? Well, how about the third variant: Reporting Issues? I'm still for 'reproduce' because a bug can be (non-)reproducible but not recreatable. Any other opinions? Ok, reproduce is fine I'd say: If you have any questions, discuss them... That's even better :) Cool!:) All patches, such as tests and fixes, should be Good! It's clearer. Fine! OK. I'll prepare patch update then. Good luck! I'd be glad to review it, if you do not mind. :) Cheers, Sveta Thanks, Alexey. Best regards, Sveta -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 1:33 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:01 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've just submitted a new JIRA [http://issues.apache.org/jira/browse/HARMONY-2110]. I've added the necessary links from the website to the new page and have tried to perfect it a little. It would be great, if you could find a chance to look through the patch. Thanks in advance. Sveta, I've taken a look and added my comments to the JIRA itself. Regards, Alexey. Best regards, Sveta -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 11:18 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Good! Go ahead. Do you need help? I can review the patch - just let me know when you submit the JIRA. Thank you, Nadya Morozova -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 9:13 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya wrote: Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html +1 it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. If you do not mind, I can create the necessary patches. Best regards, Sveta Konovalova -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 8:24 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Well, I guess the simplest solution would be to add the link to the Conventions section on the front page of wiki. You can do it yourself! Adding a link from the static website would also be useful. Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 4:44 PM To: harmony-dev@incubator.apache.org Subject: Re:
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexey, I agree that the structure of the resulting HTML website page does not appear too linear. When editing the structure, I saw the additional table - and left as is; maybe, because I hoped somebody added it on some purpose. For me, the only matter of convenience is that all content that is varied on the page is in a separate table. If nobody has an idea why the structure is so complex, we can simplify it. The structure is defined in file site.vsl in site/xdocs/stylesheets. A JIRA with patch is welcome as usual. Thank you, Nadya Morozova -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 5:20 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Sveta, all, I've attached the updated patch to the JIRA. Please review. Regards, Alexey. P.S. By the way, do we really need to place all the main content into another table? I've just looked at the source of the generated HTML file, and found it quite confusing. I agree to have a table to format the heading of the page and the list of contents on the left, but why there's another table where the main content is. I am about this one: /ul !-- end of the list of contents -- /td !-- end of list of contents cell -- td width=80% valign=topa name=top/a !-- the main content goes in this cell -- table cellspacing=0 cellpadding=2 width=100% !-- why is this table here -- trtd h1 a name=Good Issue Resolution GuidelineGood Issue Resolution Guideline/a /h1 /td/tr trtd... !-- and so on -- The comments here are added by me, and the source is slightly reformatted. I believe, the body part of the XML can be placed almost as is in the content cell of the top-level table without the need for another table because it's useless here. Or is it just Anakia limitation? -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 3:50 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Alexey, I'd change the heading Reporting the Issue to Reporting an Issue, or omit article at all. Well, both articles seem to be fine. Let it be a/an Maybe just omit articles then? Well, how about the third variant: Reporting Issues? I'm still for 'reproduce' because a bug can be (non-)reproducible but not recreatable. Any other opinions? Ok, reproduce is fine I'd say: If you have any questions, discuss them... That's even better :) Cool!:) All patches, such as tests and fixes, should be Good! It's clearer. Fine! OK. I'll prepare patch update then. Good luck! I'd be glad to review it, if you do not mind. :) Cheers, Sveta Thanks, Alexey. Best regards, Sveta -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 1:33 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:01 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've just submitted a new JIRA [http://issues.apache.org/jira/browse/HARMONY-2110]. I've added the necessary links from the website to the new page and have tried to perfect it a little. It would be great, if you could find a chance to look through the patch. Thanks in advance. Sveta, I've taken a look and added my comments to the JIRA itself. Regards, Alexey. Best regards, Sveta -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 11:18 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Good! Go ahead. Do you need help? I can review the patch - just let me know when you submit the JIRA. Thank you, Nadya Morozova -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 9:13 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya wrote: Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html +1 it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. If you do not mind, I can create the necessary patches. Best regards, Sveta Konovalova -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexey, Thanks for the patch. I've looked it through and have fixed certain issues. The new patch is created (Harmony-2110). It'd be great, if you could find a chance to review it. Best regards, Sveta -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 5:20 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Sveta, all, I've attached the updated patch to the JIRA. Please review. Regards, Alexey. P.S. By the way, do we really need to place all the main content into another table? I've just looked at the source of the generated HTML file, and found it quite confusing. I agree to have a table to format the heading of the page and the list of contents on the left, but why there's another table where the main content is. I am about this one: /ul !-- end of the list of contents -- /td !-- end of list of contents cell -- td width=80% valign=topa name=top/a !-- the main content goes in this cell -- table cellspacing=0 cellpadding=2 width=100% !-- why is this table here -- trtd h1 a name=Good Issue Resolution GuidelineGood Issue Resolution Guideline/a /h1 /td/tr trtd... !-- and so on -- The comments here are added by me, and the source is slightly reformatted. I believe, the body part of the XML can be placed almost as is in the content cell of the top-level table without the need for another table because it's useless here. Or is it just Anakia limitation? -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 3:50 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Alexey, I'd change the heading Reporting the Issue to Reporting an Issue, or omit article at all. Well, both articles seem to be fine. Let it be a/an Maybe just omit articles then? Well, how about the third variant: Reporting Issues? I'm still for 'reproduce' because a bug can be (non-)reproducible but not recreatable. Any other opinions? Ok, reproduce is fine I'd say: If you have any questions, discuss them... That's even better :) Cool!:) All patches, such as tests and fixes, should be Good! It's clearer. Fine! OK. I'll prepare patch update then. Good luck! I'd be glad to review it, if you do not mind. :) Cheers, Sveta Thanks, Alexey. Best regards, Sveta -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 1:33 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:01 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've just submitted a new JIRA [http://issues.apache.org/jira/browse/HARMONY-2110]. I've added the necessary links from the website to the new page and have tried to perfect it a little. It would be great, if you could find a chance to look through the patch. Thanks in advance. Sveta, I've taken a look and added my comments to the JIRA itself. Regards, Alexey. Best regards, Sveta -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 11:18 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Good! Go ahead. Do you need help? I can review the patch - just let me know when you submit the JIRA. Thank you, Nadya Morozova -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 9:13 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya wrote: Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html +1 it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. If you do not mind, I can create the necessary patches. Best regards, Sveta Konovalova -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 8:24 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Well, I guess the simplest solution would be to add the link to the Conventions section on the front page of wiki. You can do it yourself! Adding a
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Hi, Do we really need a smiley in the header: Resolution Provider :)? AFAIK, for headings one should use Title Capitalization, i.e. first letter of each word is capitalized with exception for articles, prepositions, and conjunctions. Or am I wrong? Does anyone mind to mark up file names (build.xml) and paths (https://svn.apache.org/...) in monospaced font using code tags? Is it worth making repository path a link? And another comment. Will it be better to use different numbering in lists? I mean like this: 1. Issue is probably a non-bug... a. Discuss on dev-list. b. Add a link... 2. Issue is a bug: a. Notify the community... b. If reporter did not provide a patch to test... Any comments? Regards, -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 1:32 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've published Good issue resolution guideline on Harmony site: http://incubator.apache.org/harmony/issue_resolution_guideline.html (wait for a while for the web site synchronization). It is not linked to other pages yet. So comments to guideline and link place suggestions are welcome. SY, Alexey 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. 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/trunk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. 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 resolution. 2.9. Add revision info into JIRA issue === cut === -- Alexey A. Petrenko Intel Middleware Products Division
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexey wrote: Do we really need a smiley in the header: Resolution Provider :)? Of course not, since it's not just a friendly correspondence:) suggest to remove. AFAIK, for headings one should use Title Capitalization, i.e. first letter of each word is capitalized with exception for articles, prepositions, and conjunctions. Or am I wrong? You are absolutely right here. And another comment. Will it be better to use different numbering in lists? I mean like this: 1. Issue is probably a non-bug... a. Discuss on dev-list. b. Add a link... 2. Issue is a bug: a. Notify the community... b. If reporter did not provide a patch to test... I, personally, do not see any reason why not to use different numbering. For such complex lists, we usually use numbers for the first level and bullets for the second one. Speaking about the Good issue resolution guideline page, I'd rewrite it to get rid of complex lists and to avoid a sort of confusion: If the issue is not a bug, ...: 1. Discuss on dev-list. 2. Add a link... If the issue is a bug,...: 1. Notify the community... 2. If reporter did not provide a patch to test... What would you say? By the way, I'm going to create a patch to add links from the website to this page. If you do not mind, I can correct the page as well in between times... how about that? Best regards, Sveta Konovalova -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 1:50 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Hi, Do we really need a smiley in the header: Resolution Provider :)? AFAIK, for headings one should use Title Capitalization, i.e. first letter of each word is capitalized with exception for articles, prepositions, and conjunctions. Or am I wrong? Does anyone mind to mark up file names (build.xml) and paths (https://svn.apache.org/...) in monospaced font using code tags? Is it worth making repository path a link? And another comment. Will it be better to use different numbering in lists? I mean like this: 1. Issue is probably a non-bug... a. Discuss on dev-list. b. Add a link... 2. Issue is a bug: a. Notify the community... b. If reporter did not provide a patch to test... Any comments? Regards, -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 1:32 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've published Good issue resolution guideline on Harmony site: http://incubator.apache.org/harmony/issue_resolution_guideline.html (wait for a while for the web site synchronization). It is not linked to other pages yet. So comments to guideline and link place suggestions are welcome. SY, Alexey 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. If you cannot produce a patch, add another comment with the results of your
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
I've just submitted a new JIRA [http://issues.apache.org/jira/browse/HARMONY-2110]. I've added the necessary links from the website to the new page and have tried to perfect it a little. It would be great, if you could find a chance to look through the patch. Thanks in advance. Best regards, Sveta -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 11:18 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Good! Go ahead. Do you need help? I can review the patch - just let me know when you submit the JIRA. Thank you, Nadya Morozova -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 9:13 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya wrote: Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html +1 it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. If you do not mind, I can create the necessary patches. Best regards, Sveta Konovalova -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 8:24 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Well, I guess the simplest solution would be to add the link to the Conventions section on the front page of wiki. You can do it yourself! Adding a link from the static website would also be useful. Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 4:44 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya, we definetly need a link to this page. That's not a question. Question is where to place the link. And as I said in previous email link place suggestions are welcome. SY, Alexey 2006/11/7, Morozova, Nadezhda [EMAIL PROTECTED]: Alexey, Would be great if there we some page that had a link to the page; otherwise, you cannot find it from within wiki, only from the link in your mail :( Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 1:32 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've published Good issue resolution guideline on Harmony site: http://incubator.apache.org/harmony/issue_resolution_guideline.html (wait for a while for the web site synchronization). It is not linked to other pages yet. So comments to guideline and link place suggestions are welcome. SY, Alexey 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
I've published Good issue resolution guideline on Harmony site: http://incubator.apache.org/harmony/issue_resolution_guideline.html (wait for a while for the web site synchronization). It is not linked to other pages yet. So comments to guideline and link place suggestions are welcome. SY, Alexey 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. 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/trunk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. 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 resolution. 2.9. Add revision info into JIRA issue === cut === -- 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]
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexey, Would be great if there we some page that had a link to the page; otherwise, you cannot find it from within wiki, only from the link in your mail :( Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 1:32 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've published Good issue resolution guideline on Harmony site: http://incubator.apache.org/harmony/issue_resolution_guideline.html (wait for a while for the web site synchronization). It is not linked to other pages yet. So comments to guideline and link place suggestions are welcome. SY, Alexey 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. 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/trunk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. 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 resolution. 2.9. Add revision info into JIRA issue === cut === -- 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Nadya, we definetly need a link to this page. That's not a question. Question is where to place the link. And as I said in previous email link place suggestions are welcome. SY, Alexey 2006/11/7, Morozova, Nadezhda [EMAIL PROTECTED]: Alexey, Would be great if there we some page that had a link to the page; otherwise, you cannot find it from within wiki, only from the link in your mail :( Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 1:32 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've published Good issue resolution guideline on Harmony site: http://incubator.apache.org/harmony/issue_resolution_guideline.html (wait for a while for the web site synchronization). It is not linked to other pages yet. So comments to guideline and link place suggestions are welcome. SY, Alexey 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. 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/trunk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. 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 resolution. 2.9. Add revision info into JIRA issue === cut === -- 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
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Well, I guess the simplest solution would be to add the link to the Conventions section on the front page of wiki. You can do it yourself! Adding a link from the static website would also be useful. Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 4:44 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya, we definetly need a link to this page. That's not a question. Question is where to place the link. And as I said in previous email link place suggestions are welcome. SY, Alexey 2006/11/7, Morozova, Nadezhda [EMAIL PROTECTED]: Alexey, Would be great if there we some page that had a link to the page; otherwise, you cannot find it from within wiki, only from the link in your mail :( Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 1:32 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've published Good issue resolution guideline on Harmony site: http://incubator.apache.org/harmony/issue_resolution_guideline.html (wait for a while for the web site synchronization). It is not linked to other pages yet. So comments to guideline and link place suggestions are welcome. SY, Alexey 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. 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/trunk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. 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.
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Nadya wrote: Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html +1 it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. If you do not mind, I can create the necessary patches. Best regards, Sveta Konovalova -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 8:24 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Well, I guess the simplest solution would be to add the link to the Conventions section on the front page of wiki. You can do it yourself! Adding a link from the static website would also be useful. Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 4:44 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya, we definetly need a link to this page. That's not a question. Question is where to place the link. And as I said in previous email link place suggestions are welcome. SY, Alexey 2006/11/7, Morozova, Nadezhda [EMAIL PROTECTED]: Alexey, Would be great if there we some page that had a link to the page; otherwise, you cannot find it from within wiki, only from the link in your mail :( Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 1:32 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've published Good issue resolution guideline on Harmony site: http://incubator.apache.org/harmony/issue_resolution_guideline.html (wait for a while for the web site synchronization). It is not linked to other pages yet. So comments to guideline and link place suggestions are welcome. SY, Alexey 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. 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/trunk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
2006/11/6, Fedotov, Alexei A [EMAIL PROTECTED]: Alexey, I started looking into this thread. Are guidelines on the web site already? I failed to find them. No, this guideline is not published yet. I'll do this in the nearest future. I thought about adding them to get-involved.html. Here are few problems I've noticed: First of all As you know patches are always welcome in Harmony :) 1. The detail level of your instruction is somewhat different from get-involved.html. This text is formal, while the text on the page is quite informal. I do not see problem here. 2. If a guy has a test in a separate file, should he produce a patch from such file and submit the patch? According to guidelines, the answer is yes. Do you mean in a new file? Yes, a new file should be provided as a patch too. Why not? According to my common sense patches are good when you modify existing files. Yes, they are good for modified files. And they also can be used for adding and removing files. 3. Why it is not suggested for an issue reporter to try localizing a buggy module I think that points 2 and 3 are saying this. or even fixing the problem? Nobody said that an issue reporter can not be a resolution provider. 4. Item 4. of issue reporter guidelines doesn't contain enough details for my taste. I believe links should be descriptive: Link the issue to previous posts, JIRAs, RI bugs, etc. Probably your sentence is better. Need to think. 5. The item 2.1 of resolution provider guidelines contains too many details to my mind. Here should be something like a following text (for all roles): a. Update JIRA once per day reporting your progress. b. Always keep the community posted. What for? Why do you want to have DAILY posts on ALL the working issues? I think that we do not need to change anything here since comunity has agreed on the list of notifications it wants to see. And all these cases are described there. 6. The item 2.4 refers to class library build.xml as a main build.xml. Patches are welcome :) 7. You do not specify which unit tests should pass and which VM should be used. Since the changes could affect DRLVM, I would say that all unit tests should pass for DRLVM unless the fall into exclude list. DRLVM is not the only Harmony VM. I think that developer can choose which VM to use. 8. I believe a verification stage should happen before committer commits a patch - this would save his time if the issue doesn't resolve the problem. Yes, and nobody argue with this. SY, Alexey -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 5:02 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) :) Yes, I'll prepare a patch. 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. 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.
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexey, Thank you for your answer. Yesterday I tried to prepare an appropriate patch for get-involved.html but faced several things I couldn't resolve myself. I didn't criticize your text - I was thinking how to fit it into get-involved.html. That is why I raised all these questions. I still have one question which is important, to my mind. You wrote, DRLVM is not the only Harmony VM. I think that developer can choose which VM to use. 1. As Geir says, we are small community, and we need to keep ourselves concentrated. Can we give a recommendation to concentrate on one specific VM assuming that VM which is shipped with Harmony 1.0? 2. What is the status of DRLVM smoke tests? As any tests written in java they have a dependency from a class library. Do you think they should be skipped while testing the patch? With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Monday, November 06, 2006 2:03 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) 2006/11/6, Fedotov, Alexei A [EMAIL PROTECTED]: Alexey, I started looking into this thread. Are guidelines on the web site already? I failed to find them. No, this guideline is not published yet. I'll do this in the nearest future. I thought about adding them to get-involved.html. Here are few problems I've noticed: First of all As you know patches are always welcome in Harmony :) 1. The detail level of your instruction is somewhat different from get-involved.html. This text is formal, while the text on the page is quite informal. I do not see problem here. 2. If a guy has a test in a separate file, should he produce a patch from such file and submit the patch? According to guidelines, the answer is yes. Do you mean in a new file? Yes, a new file should be provided as a patch too. Why not? According to my common sense patches are good when you modify existing files. Yes, they are good for modified files. And they also can be used for adding and removing files. 3. Why it is not suggested for an issue reporter to try localizing a buggy module I think that points 2 and 3 are saying this. or even fixing the problem? Nobody said that an issue reporter can not be a resolution provider. 4. Item 4. of issue reporter guidelines doesn't contain enough details for my taste. I believe links should be descriptive: Link the issue to previous posts, JIRAs, RI bugs, etc. Probably your sentence is better. Need to think. 5. The item 2.1 of resolution provider guidelines contains too many details to my mind. Here should be something like a following text (for all roles): a. Update JIRA once per day reporting your progress. b. Always keep the community posted. What for? Why do you want to have DAILY posts on ALL the working issues? I think that we do not need to change anything here since comunity has agreed on the list of notifications it wants to see. And all these cases are described there. 6. The item 2.4 refers to class library build.xml as a main build.xml. Patches are welcome :) 7. You do not specify which unit tests should pass and which VM should be used. Since the changes could affect DRLVM, I would say that all unit tests should pass for DRLVM unless the fall into exclude list. DRLVM is not the only Harmony VM. I think that developer can choose which VM to use. 8. I believe a verification stage should happen before committer commits a patch - this would save his time if the issue doesn't resolve the problem. Yes, and nobody argue with this. SY, Alexey -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 5:02 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) :) Yes, I'll prepare a patch. 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
All, I have added a patch to http://issues.apache.org/jira/browse/HARMONY-2077 [doc] Good issue resolution guideline, though some things are rephrased though. On 11/6/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Alexey, Thank you for your answer. Yesterday I tried to prepare an appropriate patch for get-involved.html but faced several things I couldn't resolve myself. I didn't criticize your text - I was thinking how to fit it into get-involved.html. That is why I raised all these questions. I still have one question which is important, to my mind. You wrote, DRLVM is not the only Harmony VM. I think that developer can choose which VM to use. 1. As Geir says, we are small community, and we need to keep ourselves concentrated. Can we give a recommendation to concentrate on one specific VM assuming that VM which is shipped with Harmony 1.0? 2. What is the status of DRLVM smoke tests? As any tests written in java they have a dependency from a class library. Do you think they should be skipped while testing the patch? With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Monday, November 06, 2006 2:03 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) 2006/11/6, Fedotov, Alexei A [EMAIL PROTECTED]: Alexey, I started looking into this thread. Are guidelines on the web site already? I failed to find them. No, this guideline is not published yet. I'll do this in the nearest future. I thought about adding them to get-involved.html. Here are few problems I've noticed: First of all As you know patches are always welcome in Harmony :) 1. The detail level of your instruction is somewhat different from get-involved.html. This text is formal, while the text on the page is quite informal. I do not see problem here. 2. If a guy has a test in a separate file, should he produce a patch from such file and submit the patch? According to guidelines, the answer is yes. Do you mean in a new file? Yes, a new file should be provided as a patch too. Why not? According to my common sense patches are good when you modify existing files. Yes, they are good for modified files. And they also can be used for adding and removing files. 3. Why it is not suggested for an issue reporter to try localizing a buggy module I think that points 2 and 3 are saying this. or even fixing the problem? Nobody said that an issue reporter can not be a resolution provider. 4. Item 4. of issue reporter guidelines doesn't contain enough details for my taste. I believe links should be descriptive: Link the issue to previous posts, JIRAs, RI bugs, etc. Probably your sentence is better. Need to think. 5. The item 2.1 of resolution provider guidelines contains too many details to my mind. Here should be something like a following text (for all roles): a. Update JIRA once per day reporting your progress. b. Always keep the community posted. What for? Why do you want to have DAILY posts on ALL the working issues? I think that we do not need to change anything here since comunity has agreed on the list of notifications it wants to see. And all these cases are described there. 6. The item 2.4 refers to class library build.xml as a main build.xml. Patches are welcome :) 7. You do not specify which unit tests should pass and which VM should be used. Since the changes could affect DRLVM, I would say that all unit tests should pass for DRLVM unless the fall into exclude list. DRLVM is not the only Harmony VM. I think that developer can choose which VM to use. 8. I believe a verification stage should happen before committer commits a patch - this would save his time if the issue doesn't resolve the problem. Yes, and nobody argue with this. SY, Alexey -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 5:02 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) :) Yes, I'll prepare a patch. 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === cut === Preface This guideline covers a
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
2006/11/6, Alexei Fedotov [EMAIL PROTECTED]: All, I have added a patch to http://issues.apache.org/jira/browse/HARMONY-2077 [doc] Good issue resolution guideline, though some things are rephrased though. I do not think that we need to insert this guideline to get involved page. I personally prefer separate document. And text in your patch looks totally different to the text which was agreed on harmony-dev list. SY, Alexey On 11/6/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Alexey, Thank you for your answer. Yesterday I tried to prepare an appropriate patch for get-involved.html but faced several things I couldn't resolve myself. I didn't criticize your text - I was thinking how to fit it into get-involved.html. That is why I raised all these questions. I still have one question which is important, to my mind. You wrote, DRLVM is not the only Harmony VM. I think that developer can choose which VM to use. 1. As Geir says, we are small community, and we need to keep ourselves concentrated. Can we give a recommendation to concentrate on one specific VM assuming that VM which is shipped with Harmony 1.0? 2. What is the status of DRLVM smoke tests? As any tests written in java they have a dependency from a class library. Do you think they should be skipped while testing the patch? With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Monday, November 06, 2006 2:03 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) 2006/11/6, Fedotov, Alexei A [EMAIL PROTECTED]: Alexey, I started looking into this thread. Are guidelines on the web site already? I failed to find them. No, this guideline is not published yet. I'll do this in the nearest future. I thought about adding them to get-involved.html. Here are few problems I've noticed: First of all As you know patches are always welcome in Harmony :) 1. The detail level of your instruction is somewhat different from get-involved.html. This text is formal, while the text on the page is quite informal. I do not see problem here. 2. If a guy has a test in a separate file, should he produce a patch from such file and submit the patch? According to guidelines, the answer is yes. Do you mean in a new file? Yes, a new file should be provided as a patch too. Why not? According to my common sense patches are good when you modify existing files. Yes, they are good for modified files. And they also can be used for adding and removing files. 3. Why it is not suggested for an issue reporter to try localizing a buggy module I think that points 2 and 3 are saying this. or even fixing the problem? Nobody said that an issue reporter can not be a resolution provider. 4. Item 4. of issue reporter guidelines doesn't contain enough details for my taste. I believe links should be descriptive: Link the issue to previous posts, JIRAs, RI bugs, etc. Probably your sentence is better. Need to think. 5. The item 2.1 of resolution provider guidelines contains too many details to my mind. Here should be something like a following text (for all roles): a. Update JIRA once per day reporting your progress. b. Always keep the community posted. What for? Why do you want to have DAILY posts on ALL the working issues? I think that we do not need to change anything here since comunity has agreed on the list of notifications it wants to see. And all these cases are described there. 6. The item 2.4 refers to class library build.xml as a main build.xml. Patches are welcome :) 7. You do not specify which unit tests should pass and which VM should be used. Since the changes could affect DRLVM, I would say that all unit tests should pass for DRLVM unless the fall into exclude list. DRLVM is not the only Harmony VM. I think that developer can choose which VM to use. 8. I believe a verification stage should happen before committer commits a patch - this would save his time if the issue doesn't resolve the problem. Yes, and nobody argue with this. SY, Alexey -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 5:02 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) :) Yes, I'll prepare a patch. 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexey, I started looking into this thread. Are guidelines on the web site already? I failed to find them. I thought about adding them to get-involved.html. Here are few problems I've noticed: 1. The detail level of your instruction is somewhat different from get-involved.html. This text is formal, while the text on the page is quite informal. 2. If a guy has a test in a separate file, should he produce a patch from such file and submit the patch? According to guidelines, the answer is yes. According to my common sense patches are good when you modify existing files. 3. Why it is not suggested for an issue reporter to try localizing a buggy module or even fixing the problem? 4. Item 4. of issue reporter guidelines doesn't contain enough details for my taste. I believe links should be descriptive: Link the issue to previous posts, JIRAs, RI bugs, etc. 5. The item 2.1 of resolution provider guidelines contains too many details to my mind. Here should be something like a following text (for all roles): a. Update JIRA once per day reporting your progress. b. Always keep the community posted. 6. The item 2.4 refers to class library build.xml as a main build.xml. 7. You do not specify which unit tests should pass and which VM should be used. Since the changes could affect DRLVM, I would say that all unit tests should pass for DRLVM unless the fall into exclude list. 8. I believe a verification stage should happen before committer commits a patch - this would save his time if the issue doesn't resolve the problem. Overall the text is great and worth to be posted in any case. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 5:02 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) :) Yes, I'll prepare a patch. 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. 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/trunk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. 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/trunk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. 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 resolution. 2.9. Add revision info into JIRA issue === cut === -- 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]
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
+1 for Wiki. This is a more edit-friendly solution. I can also add a link to your Wiki page from the website - for people to know where to look for guidelines ;) Best regards, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 11:21 AM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. 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/tru nk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. 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 resolution. 2.9. Add revision info into JIRA issue === cut === -- 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
I agree with Tim. This should be a stable document not one that needs frequent updates (which would only mean contributors would be expected to check it more often). Changes should be discussed/agreed first, thus using JIRA/svn would seem reasonable for this document. -Mark. On 28 September 2006 at 10:46, Tim Ellison [EMAIL PROTECTED] wrote: I'm not trying to be contrary - honest g - but I would suggest the website. It is a reference document that doesn't need a collaboration area on the wiki. The document has undergone review and should be stable now. My 2c. Tim Morozova, Nadezhda wrote: +1 for Wiki. This is a more edit-friendly solution. I can also add a link to your Wiki page from the website - for people to know where to look for guidelines ;) Best regards, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 11:21 AM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. 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/tru nk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. 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 resolution. 2.9. Add revision info into JIRA issue === cut === -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
+1 for the website. I agree with Mark that the changes to this document shoud be discussed first. On 9/28/06, Mark Hindess [EMAIL PROTECTED] wrote: I agree with Tim. This should be a stable document not one that needs frequent updates (which would only mean contributors would be expected to check it more often). Changes should be discussed/agreed first, thus using JIRA/svn would seem reasonable for this document. -Mark. On 28 September 2006 at 10:46, Tim Ellison [EMAIL PROTECTED] wrote: I'm not trying to be contrary - honest g - but I would suggest the website. It is a reference document that doesn't need a collaboration area on the wiki. The document has undergone review and should be stable now. My 2c. Tim Morozova, Nadezhda wrote: +1 for Wiki. This is a more edit-friendly solution. I can also add a link to your Wiki page from the website - for people to know where to look for guidelines ;) Best regards, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 11:21 AM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. 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/tru nk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. 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 resolution. 2.9. Add revision info into JIRA issue === cut === -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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:
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
No arguments against web-site :) 2006/9/28, Oleg Khaschansky [EMAIL PROTECTED]: +1 for the website. I agree with Mark that the changes to this document shoud be discussed first. On 9/28/06, Mark Hindess [EMAIL PROTECTED] wrote: I agree with Tim. This should be a stable document not one that needs frequent updates (which would only mean contributors would be expected to check it more often). Changes should be discussed/agreed first, thus using JIRA/svn would seem reasonable for this document. -Mark. On 28 September 2006 at 10:46, Tim Ellison [EMAIL PROTECTED] wrote: I'm not trying to be contrary - honest g - but I would suggest the website. It is a reference document that doesn't need a collaboration area on the wiki. The document has undergone review and should be stable now. My 2c. Tim Morozova, Nadezhda wrote: +1 for Wiki. This is a more edit-friendly solution. I can also add a link to your Wiki page from the website - for people to know where to look for guidelines ;) Best regards, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 11:21 AM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. 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/tru nk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. 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 resolution. 2.9. Add revision info into JIRA issue === cut === -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. 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/trunk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. 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 resolution. 2.9. Add revision info into JIRA issue === cut === -- 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
:) Yes, I'll prepare a patch. 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. 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/trunk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. 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 resolution. 2.9. Add revision info into JIRA issue === cut === -- 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] -- 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
This version looks good to me. Regards, 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. 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/trunk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. 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 resolution. 2.9. Add revision info into JIRA issue === cut === - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
I've combined all the comments again. And here is the last version. I hope... :) === 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 and send a message to dev list. 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/trunk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. 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 resolution. 2.9. Add revision info into JIRA issue === cut === - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On Sep 21, 2006, at 1:30 AM, Alexey Petrenko wrote: 2006/9/20, Geir Magnusson Jr. [EMAIL PROTECTED]: I still don't think that people should only be notifying the community about indications of interest or such only in the JIRA. Sending mail to the dev list should also be in there. Do we really need that? I'm afraid that dev list will be flooded by the large number of small similar messages like I'll try to prepare a patch to issue #. And most of dev list readers will not be interested in the most of this messages. I don't think that we'll be flooded, and I think that if we are we can change it. I see the mail lists as the primary communication medium of the project. By just encouraging people to comment in the JIRA, you are effectively establishing a parallel communications channel (remember, we've seen conversations happen entirely in JIRA). Conversation among people expressing interest and others that are interested in watching or helping or such will happen easier if there's one place. When people are annotating JIRAs and not mentioning anything to the dev list, I think those conversations won't happen, and we'll be poorer for it. From the other hand a man who is interested in particular issue can easily check the issue state online or even subscribe to receive all the issue changes in JIRA. And people who wants to receive all the notification can subscribe to harmony-commits list. Anyway JIRA can be configured to send all the notifications to dev list if you think that this info will be useful for everybody. I don't think we want all JIRA notifications to go to the dev lists... there was too much noise when we did that. Also, we should as people to name patch files as HARMONY- JIRA#_whatever_.patch It's very helpful. Yes, this is useful. It seems that most of the people are using this name pattern. And adding this pattern to guideline is a good idea. SY, Alexey On Sep 20, 2006, at 2:44 AM, Alexey Petrenko 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/trunk 2.5. If the patch requires to add, remove or move some files in the 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 resolution. 2.9. Add revision info into JIRA issue - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexei Zakharov wrote: 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. :) My preference is for combined patches, if they come from the same contributor. How does it help to attach them separately? Regards, Tim 2006/9/20, Alexey Petrenko [EMAIL PROTECTED]: 2006/9/20, Mark Hindess [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: On 20 September 2006 at 13:56, Alexey Petrenko [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexey Petrenko wrote: 2006/9/20, Geir Magnusson Jr. [EMAIL PROTECTED]: I still don't think that people should only be notifying the community about indications of interest or such only in the JIRA. Sending mail to the dev list should also be in there. Do we really need that? I'm afraid that dev list will be flooded by the large number of small similar messages like I'll try to prepare a patch to issue #. And most of dev list readers will not be interested in the most of this messages. It's a low overhead to the dev list, and gives us all a sense of where work is progressing. If you see a mail with [classlib][regex] or whatever it may be a flag if you are already in that area. From the other hand a man who is interested in particular issue can easily check the issue state online or even subscribe to receive all the issue changes in JIRA. And people who wants to receive all the notification can subscribe to harmony-commits list. I'd actually like to see the link made the other way too, that is that mail referencing a HARMONY-XXX tag is linked to the JIRA issue comments page. Anyway JIRA can be configured to send all the notifications to dev list if you think that this info will be useful for everybody. It's already sent to the commit list -- that is fine. Regards, Tim Also, we should as people to name patch files as HARMONY- JIRA#_whatever_.patch It's very helpful. Yes, this is useful. It seems that most of the people are using this name pattern. And adding this pattern to guideline is a good idea. SY, Alexey On Sep 20, 2006, at 2:44 AM, Alexey Petrenko 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/trunk 2.5. If the patch requires to add, remove or move some files in the 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 resolution. 2.9. Add revision info into JIRA issue - 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] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use :
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
2006/9/21, Tim Ellison [EMAIL PROTECTED]: Alexei Zakharov wrote: 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. :) My preference is for combined patches, if they come from the same contributor. How does it help to attach them separately? There was an opinion that it is good to apply a test patch first and make sure that it fails before the fix. And then make sure that it does not fail any more. Regards, Tim 2006/9/20, Alexey Petrenko [EMAIL PROTECTED]: 2006/9/20, Mark Hindess [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: On 20 September 2006 at 13:56, Alexey Petrenko [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
YES PLEASE :) On Sep 21, 2006, at 6:37 AM, Alexei Zakharov wrote: 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 [EMAIL PROTECTED]: 2006/9/20, Mark Hindess [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: On 20 September 2006 at 13:56, Alexey Petrenko [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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.
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On Sep 21, 2006, at 9:42 AM, Tim Ellison wrote: Alexei Zakharov wrote: 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. :) My preference is for combined patches, if they come from the same contributor. How does it help to attach them separately? I think it makes it cleaner. You can apply the test patch, w/o the code mods, and then run and show the tests fail. THen apply the code patch, show that things get fixed. geir Regards, Tim 2006/9/20, Alexey Petrenko [EMAIL PROTECTED]: 2006/9/20, Mark Hindess [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: On 20 September 2006 at 13:56, Alexey Petrenko [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
How does it help to attach them separately? Just to implement the algorithm for committers described earlier by Alexey: 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. ... Regards, 2006/9/21, Tim Ellison [EMAIL PROTECTED]: Alexei Zakharov wrote: 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. :) My preference is for combined patches, if they come from the same contributor. How does it help to attach them separately? Regards, Tim 2006/9/20, Alexey Petrenko [EMAIL PROTECTED]: 2006/9/20, Mark Hindess [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: On 20 September 2006 at 13:56, Alexey Petrenko [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexei Zakharov wrote: How does it help to attach them separately? Just to implement the algorithm for committers described earlier by Alexey: 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. ... Pah, get yourself a decent patch tool and apply it selectively ;-) Seriously though, I don't care if the test and fix are separate or combined. Regards, Tim 2006/9/21, Tim Ellison [EMAIL PROTECTED]: Alexei Zakharov wrote: 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. :) My preference is for combined patches, if they come from the same contributor. How does it help to attach them separately? Regards, Tim 2006/9/20, Alexey Petrenko [EMAIL PROTECTED]: 2006/9/20, Mark Hindess [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: On 20 September 2006 at 13:56, Alexey Petrenko [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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.
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On Sep 21, 2006, at 3:27 PM, Tim Ellison wrote: Alexei Zakharov wrote: How does it help to attach them separately? Just to implement the algorithm for committers described earlier by Alexey: 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. ... Pah, get yourself a decent patch tool and apply it selectively ;-) Seriously though, I don't care if the test and fix are separate or combined. I do. what tool do you suggest? Regards, Tim 2006/9/21, Tim Ellison [EMAIL PROTECTED]: Alexei Zakharov wrote: 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. :) My preference is for combined patches, if they come from the same contributor. How does it help to attach them separately? Regards, Tim 2006/9/20, Alexey Petrenko [EMAIL PROTECTED]: 2006/9/20, Mark Hindess [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: On 20 September 2006 at 13:56, Alexey Petrenko [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Geir Magnusson Jr. wrote: I do. what tool do you suggest? I use Eclipse and TortoiseSVN patch tools at different times. Both allow you to read a combined patch, but update only a subset of affected files. Like I said though, I don't feel strongly so recommending separate patches is ok by me if it helps others. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
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/trunk 2.5. If the patch requires to add, remove or move some files in the 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 resolution. 2.9. Add revision info into JIRA issue - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
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/trunk 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/trunk/modules/module_name Generally, making the patch from this directory is much faster then from the classlib/trunk :) On 9/20/06, Alexey Petrenko [EMAIL PROTECTED] 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/trunk 2.5. If the patch requires to add, remove or move some files in the 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 resolution. 2.9. Add revision info into JIRA issue - 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
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. 2006/9/20, Oleg Khaschansky [EMAIL PROTECTED]: 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/trunk 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/trunk/modules/module_name Generally, making the patch from this directory is much faster then from the classlib/trunk :) On 9/20/06, Alexey Petrenko [EMAIL PROTECTED] 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/trunk 2.5. If the patch requires to add, remove or move some files in the 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 resolution. 2.9. Add revision info into JIRA issue - 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On 20 September 2006 at 13:56, Alexey Petrenko [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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/trunk 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/trunk/ modules/module_name Generally, making the patch from this directory is much faster then from the classlib/trunk :) On 9/20/06, Alexey Petrenko [EMAIL PROTECTED] 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 the 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 resolution. 2.9. Add revision info into JIRA issue - 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
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 [EMAIL PROTECTED]: On 20 September 2006 at 13:56, Alexey Petrenko [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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/trunk 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/trunk/ modules/module_name Generally, making the patch from this directory is much faster then from the classlib/trunk :) On 9/20/06, Alexey Petrenko [EMAIL PROTECTED] 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 the 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 resolution. 2.9. Add revision info into JIRA issue - 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:
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexey, What was wrong with the initial suggestion of recommending patches be either relative to the classlib/trunk or classlib/trunk/module/module-name? 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: On 20 September 2006 at 13:56, Alexey Petrenko [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] g
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
I still don't think that people should only be notifying the community about indications of interest or such only in the JIRA. Sending mail to the dev list should also be in there. Also, we should as people to name patch files as HARMONY- JIRA#_whatever_.patch It's very helpful. On Sep 20, 2006, at 2:44 AM, Alexey Petrenko 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/trunk 2.5. If the patch requires to add, remove or move some files in the 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 resolution. 2.9. Add revision info into JIRA issue - 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On 15 September 2006 at 8:08, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/9/15, Gregory Shimansky [EMAIL PROTECTED]: On Thursday 14 September 2006 16:55 Mark Hindess wrote: 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 This probably requires updating the page about downloading the source code on Harmony incubator site. The URL there points to the whole Harmony including standard/ and enhanced/ directories. I think there should be more detailed description about subdirectories in svn repository. I do not see any problem here. It is possible to checkout all the apache svn repository from the root but make diff from classlib/trunk :) Sure you can, but I think this is something we should discourage. If there is documentation that is encouraging this, as Gregory mentions, then it should be updated. Patches for the website would be welcome. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On 15 September 2006 at 12:18, Vladimir Gorr [EMAIL PROTECTED] wrote: 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? Yes. But the patch metadata usually contains this information - assuming people are using svn diff to create the diffs. -Mark. 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On 9/15/06, Mark Hindess [EMAIL PROTECTED] wrote: On 15 September 2006 at 12:18, Vladimir Gorr [EMAIL PROTECTED] wrote: 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? Yes. But the patch metadata usually contains this information - assuming people are using svn diff to create the diffs. Indeed someone of contributors can use another tool (say, GIT) to prepare their patches. It's a reason why I mentioned about the revision number. Thanks, Vladimir. -Mark. 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Yes, I don't think it would hurt, even if it's in the patch as Mark noted. geir Vladimir Gorr wrote: On 9/15/06, Mark Hindess [EMAIL PROTECTED] wrote: On 15 September 2006 at 12:18, Vladimir Gorr [EMAIL PROTECTED] wrote: 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? Yes. But the patch metadata usually contains this information - assuming people are using svn diff to create the diffs. Indeed someone of contributors can use another tool (say, GIT) to prepare their patches. It's a reason why I mentioned about the revision number. Thanks, Vladimir. -Mark. 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
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 community 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. Patch 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 it. 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.mbox/[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: close 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 still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the 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 regression 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 then 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 to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
2006/9/13, Alexey Petrenko [EMAIL PROTECTED]: 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 community 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. Patch to test will be highly appreciated. 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 it. 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. 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close 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 + Add revision info into JIRA issue 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 still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the 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 regression 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 then 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 to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, 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. -- Alexey A. Petrenko Intel Middleware Products Division -- 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
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] 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 community 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. Patch 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 it. 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.mbox/%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: close 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 still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the 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 regression 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 then 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 to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, for example, there may be
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Agree on both cases. We can also ask to use dos2unix utility on Windows to convert patches to unix LF fromat. 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] 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 community 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. Patch 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 it. 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.mbox/%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: close 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 still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the 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 regression 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 then 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
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] 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 community 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. Patch 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.mbo 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: close 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 still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On Thursday 14 September 2006 16:55 Mark Hindess wrote: 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 This probably requires updating the page about downloading the source code on Harmony incubator site. The URL there points to the whole Harmony including standard/ and enhanced/ directories. I think there should be more detailed description about subdirectories in svn repository. -- Gregory Shimansky, 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
2006/9/15, Gregory Shimansky [EMAIL PROTECTED]: On Thursday 14 September 2006 16:55 Mark Hindess wrote: 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 This probably requires updating the page about downloading the source code on Harmony incubator site. The URL there points to the whole Harmony including standard/ and enhanced/ directories. I think there should be more detailed description about subdirectories in svn repository. I do not see any problem here. It is possible to checkout all the apache svn repository from the root but make diff from classlib/trunk :) -- 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
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
[jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
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 community 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. Patch to test will be highly appreciated. 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 it. 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. 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close 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 still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the 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 regression 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 then 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 to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, 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. -- 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] 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 community 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. Patch to test will be highly appreciated. 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 it. 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. 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close 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? Sounds excellent! 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 still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the 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 regression 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 then 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 to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, 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. -- 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] -- Andrew Zhang China Software Development Lab, IBM
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
And the resolution provider should not forget to add a comment when he is starting development of the patch to prevent collisions. If the resolution provider is a committer he simply assigns the bug. On 9/13/06, Andrew Zhang [EMAIL PROTECTED] wrote: On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] 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 community 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. Patch to test will be highly appreciated. 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 it. 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. 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close 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? Sounds excellent! 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 still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the 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 regression 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 then 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 to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, 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. -- 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] -- Andrew Zhang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
and resolution provider should verify the application. On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] 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 community 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. Patch to test will be highly appreciated. 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 it. 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. 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close 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 still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the 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 regression 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 then 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 to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, 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. -- 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] -- Tony Wu China Software Development Lab, IBM
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] 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 community 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... Excellent ;-) Only a few comments. Issue reporter: 1. Reporter should try to create as small test case as possible. Patch to test will be highly appreciated. 2. Do not forget to use issue links if applicable. 0. Explicitly address: what is the expected behavior, and what's the actual behavior of Harmony? 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 it. 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 could also suggest some requirements for patch: e.g., avoid using absolute path, provide a shell if necessary, 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close 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 And make sure all tests pass ;-) 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 still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the 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 regression 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 then 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 to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, 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. -- 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] -- Richard Liang China Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
and resolution provider should verify the application. Or, probably, the reporter may do it also. On 9/13/06, Tony Wu [EMAIL PROTECTED] wrote: and resolution provider should verify the application. On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] 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 community 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. Patch to test will be highly appreciated. 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 it. 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. 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close 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 still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the 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 regression 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 then 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 to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, 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. -- 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] -- Tony Wu China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
2006/9/13, Richard Liang [EMAIL PROTECTED]: On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] 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 community 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... Excellent ;-) Only a few comments. Issue reporter: 1. Reporter should try to create as small test case as possible. Patch to test will be highly appreciated. 2. Do not forget to use issue links if applicable. 0. Explicitly address: what is the expected behavior, and what's the actual behavior of Harmony? Right! With the link to spec if possible. 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 it. 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 could also suggest some requirements for patch: e.g., avoid using absolute path, provide a shell if necessary, Probably such requirements can be done as separate paragraph or even separate document. And leave this instruction as a simple algorithm. 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close 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 And make sure all tests pass ;-) Right! :) 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 still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the 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 regression 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 then 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 to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, 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. -- 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] -- Richard Liang China Development Lab, IBM - 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On Wednesday 13 September 2006 18:09 Andrew Zhang wrote: On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] 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 community to prepare good fixes and will help committers to spend less time on applying other's patches. This all applies very well when test is ready and fix is simple. But when the bug requires running some application for 2 days in a row (e.g. race condition, memory leak or corruption, enumeration bug) and fix is not obvious (VM fixes are often like this) I hope such patches in JIRA won't be rejected according to these policies. -- Gregory Shimansky, 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Make your addition to the guideline. SY, Alexey 14.09.06, Gregory Shimansky[EMAIL PROTECTED] написал(а): On Wednesday 13 September 2006 18:09 Andrew Zhang wrote: On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] 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 community to prepare good fixes and will help committers to spend less time on applying other's patches. This all applies very well when test is ready and fix is simple. But when the bug requires running some application for 2 days in a row (e.g. race condition, memory leak or corruption, enumeration bug) and fix is not obvious (VM fixes are often like this) I hope such patches in JIRA won't be rejected according to these policies. -- Gregory Shimansky, 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] -- Alexey A. Petrenko Intel Middleware Products Division
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Gregory Shimansky wrote: On Wednesday 13 September 2006 18:09 Andrew Zhang wrote: On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] 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 community to prepare good fixes and will help committers to spend less time on applying other's patches. This all applies very well when test is ready and fix is simple. But when the bug requires running some application for 2 days in a row (e.g. race condition, memory leak or corruption, enumeration bug) and fix is not obvious (VM fixes are often like this) I hope such patches in JIRA won't be rejected according to these policies. No, they won't. We're setting up guidelines for the general cases... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
