On Wed, Jul 2, 2008 at 6:48 PM, Evan Gilbert <[EMAIL PROTECTED]> wrote:
> The attached patch is definitley > 100 lines (although mostly code for > testing). So this would qualify as a patch that should be discussed > beforehand? There aren't really any hard and fast rules here. Use your own judgement about the "scope" of a change. > > > Also - is there a preference for JIRA vs. email discussion? I find the JIRA > issues more difficult to follow vs. a simple email thread. JIRA's main advantage is tracking, since it integrates with SVN fairly decently. > > 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 > > > > > >
