On Aug 24, 2006, at 1:34 AM, James Strachan wrote:
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.
This is my thinking for Geronimo as well, though I don't know if it's
coming out real clear. The RTC system is already in Jira with fancy-
schmancy commit emails and everything, so if someone *wants* to use
it, why not? I.e "at your discretion."
Over time, we'd likely get some kind of rhythm going as to where it's
effective and where it makes no difference and to here it's just a
bad idea.
But the Jira thing is a given... as you say, release notes. I do my
best to file a Jira for anything the user will want to know about,
even if I've already done the work.
-David
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/
