On Fri, Oct 10, 2008 at 8:03 AM, Tim Funk <[EMAIL PROTECTED]> wrote: > If we really prefer to be particular about change logs. Then we should > create a BUGZILLA VERSION called trunk and potentially a new "product" > called tomcat 7 (or tomcat-unknown). Then any fix first goes into Bugzilla > with a description of the fix. > > Then every commit message would contain the BUGZILLA ID. This allows > multiple commits to span a single bugzilla entry. > > Then it would be trivial to get the distinct set of BUGZILLA ids and > extract with the summary (and/or) description. Likewise - it probably > wouldn't be hard to have something listening on the commits and update the > BUGZILLA entry with a with a URL to the change.
My comment was mostly about minimizing the redundant manual work, if possible ( and easy enough ). If people think it's too confusing - sure, we can use the manual file, but it would be great if the commit message would include same ( or more ) than the change log, it makes it easier to browse/understand. It is possible for the submit to include references to the issue tracker, and I think there are tools to automatically update it. But I'm not sure creating a bugzilla before any commit is reducing the redundant work :-) Anyways - it was just an idea, I'm +1 on the manual solution if people feel svn log is too verbose.. Costin > > > -- > Possible example commit message: > > bug: 12345 > bug=12345 > <bug>12345</bug> > > -- > > -Tim > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
