Hi Nigel,
Nigel Daley wrote:
Often it requires multiple changes to the code for the same issue before
everybody is happy (I think/hope this will be a very picky community :-)
and I admit I'm an infant with SVN (Perforce addict) but wouldn't a
report generated by SVN contain a lot of clutter in that case. Also for
release notes I really like the issue description instead of the
comments people in general use for their commit.
+1. I suspect a CHANGES.txt file that is hand maintained by committers
may be more useful at release time.
I always create a RELNOTES file in which I copy the JIRA generated
release notes, and provide a link to JIRA where everybody can generate
the release notes himself against a given version.
Look at
http://scm.cheiron.org:1665/@md=d&cd=//cheiron/seven/version/0.1/&cdf=//cheiron/seven/version/0.1/RELNOTES&sr=189&c=5uP@//cheiron/seven/version/0.1/RELNOTES
for an example.
If I recall correctly the Jini team didn't write a single character
before there was an issue in their tracking system. I adopted this style
and found it worth while on a rather stable codebase. I'm curious to
know what the others think of this.
In my (limited) experience with an ASF project, occasionally a JIRA is
created and a patch is attached to it all within a minute. Clearly the
person had completed the patch before creating a JIRA. Are you saying
to want to preclude this? I don't see a reason to.
I don't want to preclude that when it is only occasionally, I do that
sometimes too. But I must admit I only do it for the task that just
pop-up and can be solved in the minute (those highly rewarding ones).
Anything else has the smell of secretly working on some stuff and sneak
in with good hopes nobody notices ;-)
--
Mark
