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 add a step here to say "add a comment to the JIRA > > > > > > indicating that you are working on this bug", as suggested by Geir > > > > > > at [1]. > > > > > > > > > > > > Regards, > > > > > > Oliver > > > > > > > > > > > > [1] > > > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.m > > > bo > > > > x/%3 > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > 3. Do not forget to use issue links if applicable. > > > > > > > > > > > > > > Committer > > > > > > > 1. Issue is probably a non-bug difference, not a bug or invalid: > > clos > > > e > > > > > > > the issue. > > > > > > > 2. Issue is a bug: > > > > > > > 2.1. Apply the patch to test if it exists. > > > > > > > 2.2. Check that test fails. > > > > > > > 2.3. Apply the fix for the issue > > > > > > > 2.4. Check that test does not fail any more > > > > > > > 2.5. If there is a problem on previous steps post a comment > > to > > > > > > > JIRA and let "resolution provider" to resolve. > > > > > > > > > > > > > > Thoughts? Comments? Additions? > > > > > > > > > > > > > > SY, Alexey > > > > > > > > > > > > > > 2006/9/13, Paulex Yang <[EMAIL PROTECTED]>: > > > > > > >> Nathan Beyer wrote: > > > > > > >> > Here are a few things that I think might help with getting > > through > > > > > > >> some of > > > > > > >> > the older outstanding issues, as well as new ones. > > > > > > >> > > > > > > > >> > * If an issue is old (over a month???), then verify that it's > > stil > > > l > > > > > > >> an issue > > > > > > >> > with the latest code and note this with a JIRA comment. > > > > > > >> > * Obviously posting patches is great, but patches without > > tests ar > > > e > > > > > > >> almost > > > > > > >> > always ignored. > > > > > > >> > ** If you're posting an enhancement, post a patch that > > enhances th > > > e > > > > > > >> tests > > > > > > >> > and make sure they pass on an RI. (I always make sure the > > test > > > > > > >> passes on the > > > > > > >> > RI before considering the patch.) > > > > > > >> > ** If you're posting a fix, post a patch that includes a > > regressio > > > n > > > > > > >> test. (I > > > > > > >> > always apply the test first, then run it to see it fail, then > > I > > > > > > >> look at the > > > > > > >> > fix.) > > > > > > >> > * If there's a particular JIRA issue that you would like > > fixed and > > > > > > >> a patch > > > > > > >> > already exists, try applying the patch yourself, verify it > > and the > > > n > > > > > > >> add a > > > > > > >> > comment supporting the patch. > > > > > > >> > > > > > > > >> > > > > > > > >> > -Nathan > > > > > > >> +1 from me, this is an excellent guide. Only one more thing: > > > > > > >> > > > > > > >> * If the JIRA/patch is debatable for any reasons (non-bug > > difference > > > , > > > > > > >> break others, any other concerns...), don't hesitate to forward > > it t > > > o > > > > > > >> dev-list for discussion. > > > > > > >> > > > > > > >> And further, if possible, I suggest to look at related JIRAs in > > one > > > ru > > > > n, > > > > > > >> for example, there may be several issues/patches related to > > > > > > >> ObjectOutputStream, if you fixed/updated one, another patch may > > be > > > > > > >> outdated, a better way is to link them and consider them > > together. > > > > > > > > > > > > > > > > > > > -- > > > > > > Oliver Deakin > > > > > > IBM United Kingdom Limited > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > -- > > > > Alexey A. Petrenko > > > > Intel Middleware Products Division > > > > > > > > --------------------------------------------------------------------- > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > ------=_Part_22626_32452037.1158297490005-- --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
