The attached patch is definitley > 100 lines (although mostly code for testing). So this would qualify as a patch that should be discussed beforehand?
Also - is there a preference for JIRA vs. email discussion? I find the JIRA issues more difficult to follow vs. a simple email thread. Evan On Wed, Jul 2, 2008 at 10:02 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > On Wed, Jul 2, 2008 at 9:15 AM, Evan Gilbert <[EMAIL PROTECTED]> wrote: > > > Hi all - wanted to know if we have an official guideline on when to > create > > a JIRA issue vs. just committing a change. > > > > My instinct is that you should open a JIRA issue for changes that have a > > significant design portion or that affect APIs that are exposed by a > > library, and to commit when you are making minor changes or refactorings. > > > > That's mostly what we've been doing. Minor changes (bug fixes, > documentation > fixes, etc.) that aren't going to impact other users can be committed > without much issue. Larger changes (API changes, significant refactoring, > new classes, and pretty much any change of more than 100 lines) should have > a JIRA ticket associated with it, or at least an email discussion. When the > commit is made, that discussion is usually referenced so that we know what > the change was for. > > It's a poor man's code review system, but it seems to work out pretty well > because we get lots of scrutiny post-commit. I'll comment on the patch > itself once I get a chance to really look at it later :) > > > > > > > > For discussion purposes, I've attached a patch that I would think is well > > below the JIRA threshhold. > > > > Evan > > >
