BTW how about a new model. Lets call it JCTR. * create a JIRA * commit patch and refer to the JIRA issue in the commit comment (**) * close the JIRA * other folks review, if need be we can reopen the JIRA again, revert the patch if need be or continue amending it etc
(**) we can get JIRA to then link to the SVN revision so that folks can view the patch from JIRA so its similar to attaching a patch to JIRA just a whole lot less work) For really complex things we could still switch to full RTC if need be since the process is JIRA focussed. The basic idea is that all non-trivial changes should have a JIRA associated with them, if nothing else than to create good release notes - and we should endevour to have the SVN and JIRA's wired together better then folks can then track things via JIRA, email or SVN with them all linked together nicely. On 8/24/06, James Strachan <[EMAIL PROTECTED]> wrote:
I'm a CTR fan - every project I've ever used and have ever worked on works like that (apart from Geronimo) and its very effective, works well, allows projects to be productive and usually changes are pretty small so by reading the commit log/mails you can keep up to date. The beauty of using a SCM is you can always roll stuff back if you need to, if folks have an issue with a particular direction or change :). So in summary I'm agreeing with Guillaume - lets use CTR unless folks think there is a particular area which requires RTC for big changes or contentious issues etc. On 8/23/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > Geronimo is considering a change to its review and commit policies. > As a subproject, I think we should discuss how we would like to > handle reviewing code and when it should be committed. So... > > How do you think we should handle this process? > > What rules-of-thumb should we use to guide ourselves? > > -dain > -- James ------- http://radio.weblogs.com/0112098/
-- James ------- http://radio.weblogs.com/0112098/
