2007/2/6, Alexei Zakharov <[EMAIL PROTECTED]>:
> 5. if for any reasons, someone needed to submit a new patch for some issue, > don't delete the old one, but named the new ones with version number. I'd say I prefer to see version numbers in renewed patch names too. However, I think it is also ok to remove outdated patches sometimes. Especially in case if there are a lot of them attached to single JIRA. You can always browse "all" JIRA view to see the attachment history.
If the history can be saved and got easily somewhere, I'm fine with this issue, but I have no idea where the "all" JIRA view is? Regards,
2007/2/6, Yang Paulex <[EMAIL PROTECTED]>: > 2007/2/6, Alexey Petrenko <[EMAIL PROTECTED]>: > > > > Guys, > > > > I think we need a little update for the "Good issue resolution guideline" > > [1] > > > > I suggest the following additions to the "Resolving Issues.If the > > issue is a bug" to make committers life much easier :) > > 1. All the newly introduced message strings should be internationalized > > 2. All the patches should have an evaluation comment > > 3. If you change two lines of code please make sure that you patch > > includes only these two lines and do not include any other changes > > like code formatting. > > 4. Add yourself to the list of watchers to receive comments and > > concerns on your patch. > > > I also had some thoughts to keep the patch history, recently I reviewed and > commented some patches, and then the contributor submitted new > patches(thanks!), but they removed the old ones from JIRA. Sometimes it > makes me confused, because the patches' names are same but they are actually > a new version, further, it makes the former discussion on the JIRA invalid > because they are based on the old patches. So I'd like to propose this for > discussion: > > 5. if for any reasons, someone needed to submit a new patch for some issue, > don't delete the old one, but named the new ones with version number. > > > Thoughts? Concerns? Objections? > > > > SY, Alexey > > > > [1] http://harmony.apache.org/issue_resolution_guideline.html -- Alexei Zakharov, Intel ESSD
-- Paulex Yang China Software Development Labotary IBM
