On May 10, 2007, at 19:58 , Oliver Lietz wrote:
hehehe - I read
http://www.atlassian.com/software/jira/docs/latest/
default_workflow.html
and http://www.atlassian.com/software/jira/docs/latest/
issues.html#StatusTypes
and checked the frequency of occurrence of "Closed" and "Resolved"
just
before working on that issue in Jira today. I was also the user who
reported
the issue and tried my patches before committing them of course. So
I came to
the conclusion that using "Close" fits best.
I know, and I understand your point; in this case it's mostly that we
might still need to edit the issue before the release (changing the
fix version for instance :-D )
I'm happy with using resolve or close as long we use it in a
consistent way.
I think we do in general, but again, there's no clear rule. I think
Fabrizio does it more your way; maybe we need to discuss and settle
this down, like many other things you rightfully questioned in the
past (and others that have been bugging me, too, like javadoc for
instance <G>), but I never had the courage to sit down, list these
things and participate in the endless discussions that too often
follow these subjects...
When working on the bypasses issue I browsed through the new voting
package
and found some small things - e.g. missing license header, unnecessary
semicolon. We don't create issues in Jira for that trivial things,
do we? Is
there a rule of thumb which issues should be documented in Jira?
Other than common sense, no. On the top of my head, I would say:
- stuff that modifies the behaviour of the application
- api changes (! which should ideally be very clearly identifiable -
maybe we should even have a custom field for that so when we release
we can easily list all the api changes)
- new features, obviously
- bug fixes
... well basically anything, except <maybe>:
- fixes to new features that have never been released. i.e the
missing dms bypass wasn't *absolutely* necessary in jira. It's not
bad to have it, although it makes the changelog a bit awkward, but
it's imho only useful if you don't fix it right away, as a "reminder".
Again, no rules set in stone, so usage of good sense required.
I suggest using the SVN revision in Jira when resolving issues so
we have a
reference from SVN to Jira and also the other way round. That's the
way I do
it here with Trac and SVN. There is not a feature in Jira to link
from an
issue to the related source in SVN like there is in Trac, is it?
Adding the jira issue number in your commit message is enough: the
svn mails have links to jira, and jira has a "subversion commits" tab
that shows the commit (jira parses the repository every x hours for
new commits). There's a good chance this doesnt work with dms, since
its in a different svn directory... i'll have to check the config.
You should see it with the main magnolia project, though.
Thanks for the fix anyways ;)
in the spirit of open source - use it, improve it
Well I wish more people were seeing it this was instead of seeing a
free lunch ;)
Thanks for providing Magnolia and opening it more and more.
Yeah, I guess there are a bunch of people who deserve more credit
than me for this!
Cheers
greg
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/developer.html
----------------------------------------------------------------
