On Sep 19, 2006, at 7:57 AM, Prasad Kashyap wrote:
I am more concerned about having a ready link between a change and
it's relevant discussion. How do we maintain it ? Would people have to
take the trouble of googling the archives to search for the relevant
discussion ? This is kinda tangential to the discussion on the other
thread about having javadocs.
Going thro' subversion history doesn't necessarily provide this link.
Not all changes have the required, appropriate comments.
I would be more inclined to put the relevant comments into the
subversion commit, as IMO that is the definitive location for the
projects data. JIRA provides a view on top of subversion to better
organize tasks and bugs, and rolls that up into versions nicly... but
when something breaks, I want to be able to look at the history of
svn to see what is going on... and bouncing back and forth from svn
to JIRA because all of the details are in the JIRA would be a PITA.
Anyways, I have seen companies "force" JIRA's for every commit... in
fact I implemented that at my last gig... and it blew up because
people would just create lame JIRA issues... which just trashes up
JIRA making is overall less useful.
However, I do think that for controlled branches that it is a good
idea... but not as a general policy. General policy that dictates
forced JIRA creation for everything is a very, very, very bad idea.
This is open source... not IBM :-P
Next, are there any guidelines about when to create JIRAs and when
one can get by without ?
Well... if you contribute by patches, then you need to create an
issue, which is obvious. If you are making a non-trivial change that
should be noted in the release material then you should make an issue
(like if you are adding, changing or removing a dependency). New
features should obviously get issues, same with bugs. And I guess if
you can't decide if it needs an issue or not... then I would learn
towards creating an issue.
But more generally, JIRA issues should be used to track tasks and
bugs... not individual changes to code. The changes augment the JIRA
data, so that when looking at the issue one can get a complete (more
or less, hopefully more) picture about what was done to implement/fix
the feature/bug.
IMO, if there is a relevant JIRA, then the svn commit should include
the JIRA id (exact case, so that the JIRA svn plugin can link it
properly). The comment in svn should also include the relevant
change details, and should never (ever) just include the JIRA id...
in fact this is probably one of the only hard and fast rule that I
think is worth enforcing... that and maybe don't but in garbage into
the commit msg... I have seen it before (not here) where people just
type in random garbage (mostly with p4, since it requires a non-empty
description).
--jason
