openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <>
Subject Re: JIRA bug tracking of code changes
Date Mon, 21 Aug 2006 15:20:27 GMT
If I am resolving some particular JIRA bug or feature and I come across a
condition like Patrick pointed out...

if (someCondition)

I would just fix it as part of the JIRA bug I was already resolving.  No new
JIRA bug, no new paperwork, just resolve the issue.

But, if you come across this type of problem when you are just reviewing the
code, then having some type of "catch all" JIRA bug report might be nice.
But, it's probably not necessary.  Especially since only the approved
committers would have that luxury.  Anybody else would have to submit a


On 8/21/06, Patrick Linskey <> wrote:
> > I'm a little more nervous about "things that are wrong" unless we
> > make it clear that it's only things that have no externally visible
> > behavior. These should have real bug numbers and descriptions that
> > users can search.
> The problem is that if I stumble across code like this:
> if (someCondition)
>     doSomething;
>     doSomethingElse;
> I can objectively see that something is wrong, and, depending on the code
> in
> question, can often figure out what the right behavior is. If I need to go
> open a JIRA issue (which in turn means that I'd need to be online) just in
> order to change it, I'm much less likely to make the fix at all. I don't
> like the idea of erecting process barriers to keeping the codebase in good
> shape.
> Also, I don't fully buy into the theory that people should be able to see
> all in JIRA. I mean, they do have access to the svn repository, including
> the commit log and 'svn annotate' etc.
> Thoughts?
> -Patrick
> _______________________________________________________________________
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message