There are always small changes that are not directly tied to a
specific JIRA issue. My point is that by making it a requirement to
have a JIRA issue that people will end up creating more issues than
we really nee (or want).
I have made a lot of small changes to the build which fit into this
category. Some clean up also fits into that category. Say, adding
or fixing javadocs, or adding TODO comments, etc... all things which
probably don't have a JIRA issue and it would be a PITA to force
folks to go an make one. That is way to artificial and pointless.
--jason
On Sep 19, 2006, at 12:08 AM, Jacek Laskowski wrote:
On 9/18/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
I think it is a bad idea to force every change to have a JIRA issue
created (or associated). This will only lead to forcing people to
add a bunch of junk to JIRA.
-1 to forcing each change to have a JIRA... common sense should
dictate which changes need JIRA issues and which do not.
JIRA is more useful to track high-level coarse grained information
and bugs fixed. If you need fine grained history, look at
subversion.
Would you present some examples of changes (commits) that should not
be reported in JIRA? What changes would you make that don't fall into
some kind of high-level coarse-grained information? If they're not
part of a bigger picture, why would you care to commit them? I can't
think of any change that goes to trunk without a need for it so if
there's a need for it people will expect it to be trackable and
RELEASE NOTES are one of the excellent means. It requires that each
and every change is bound to a JIRA report, though.
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
