On 11/30/05, Don Brown <[EMAIL PROTECTED]> wrote: > Greg Reddin wrote: > > > > On Nov 30, 2005, at 1:49 PM, Don Brown wrote: > > > >> There was in the CVS days, and I don't believe I've seen it since. > >> I'm thinking something simple like: > >> Adding this new feature > >> PR: 234 > >> Type: (fix, add, update, documentation) > >> Contributed By: Sarah Jones > > > > > > Just a clarification: Are we saying every commit should have a ticket > > attached to it or will there be room for commits without that? > > The PR will be optional, however if it is a major feature, it should really > have > a ticket. I think forcing a ticket is a bit extreme :)
I agree although probably at the moment when its stuff we originate (rather than prompted by a ticket), its too much the other way. Mail threads get lost and IMO its better creating a ticket and putting feedback into that. I also like what Patrick showed from Confluence - having a combination of hand written and generated release notes. Thats what I did for Struts 1.2.7 (except it was all hand written) - have a summary to give people a flavour and then detail list of tickets. The only thing missing from Patricks was a link to the commit message. Where this breaks down (i.e. commit generated release notes) is when you have several commits for the same thing, which quite often happens as things evolve or an issue in the change comes up. Also there are alot of commits which you really don't want to publish (changing the build system, site documentation, re-organising the repository, svn properties etc) which would have to be filtered out. Maybe bug generated is a better approach to commit generated. I've started getting into the habit of pasting the commit url into the bug ticket when I close something as fixed. Thats another good way of keeping a link. Niall > Don > > > > Thanks, > > Greg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
