On 30 June 2011 21:10, Robbie Gemmell <[email protected]> wrote: > On 30 June 2011 17:56, Rajith Attapattu <[email protected]> wrote: >> On Thu, Jun 30, 2011 at 12:46 PM, Robbie Gemmell >> <[email protected]> wrote: >>> I think that is a good idea for general administrative tasks, and it >>> has certainly been suggested by others in the past. However I think >>> it is a bad idea for merges: those should all be tagged with the >>> original JIRA, just like the commit being merged should already be. >> >> I was suggesting to use it as a secondary JIRA (alongside the original). >> That way the release specific JIRA would have a record in addition the >> to original JIRA. > > Apologies, I somehow completely missed the 'secondary' in there > originally, oops :) > >> IIRC you can put several JIRAs in the commit message and JIRA/SVN is >> able to recognize them and add references accordingly. >> It doesn't hurt to have record of what exactly was ported into the >> release branch. >> >> Rajith >> > > You certainly can add multiple JIRA references to a commit, although > in my eyes the original JIRAs already should be the record of what was > ported to the release branch as we have previously created the release > version number in JIRA and used it for that purpose once branched for > release.
Which I have incidentally now done ;) Justin, I also added your JIRA account to the Cmmitters role while I was in there. Robbie > > Robbie > >>> >>> Robbie >>> >>> On 30 June 2011 15:25, Rajith Attapattu <[email protected]> wrote: >>>> This is just an idea. Instead of using NO-JIRA we could create a JIRA >>>> for 0.12 and then use that for all administrative commits related to >>>> 0.12 >>>> Ex. creating the branch, creating tags or even use that as a secondary >>>> JIRA when porting changes from trunk to release branch. >>>> >>>> The advantage here is, that there is a single place which gives you a >>>> list of all the (administrative) commits related to a particular >>>> release. >>>> It certainly provides a nice audit trail and gives the release manager >>>> an easy way to keep track of all changes going into the release >>>> branch. >>>> >>>> Regards, >>>> >>>> Rajith >>>> >>>> On Thu, Jun 30, 2011 at 10:02 AM, <[email protected]> wrote: >>>>> Author: jross >>>>> Date: Thu Jun 30 14:02:01 2011 >>>>> New Revision: 1141543 >>>>> >>>>> URL: http://svn.apache.org/viewvc?rev=1141543&view=rev >>>>> Log: >>>>> NO-JIRA: Branch for the 0.12 release >>>>> >>>>> Added: >>>>> qpid/branches/0.12/ (props changed) >>>>> - copied from r1141493, qpid/trunk/ >>>>> >>>>> Propchange: qpid/branches/0.12/ >>>>> ------------------------------------------------------------------------------ >>>>> --- svn:mergeinfo (added) >>>>> +++ svn:mergeinfo Thu Jun 30 14:02:01 2011 >>>>> @@ -0,0 +1,3 @@ >>>>> +/qpid/branches/0.5.x-dev:892761,894875 >>>>> +/qpid/branches/0.6-release-windows-installer:926803 >>>>> +/qpid/branches/java-network-refactor:805429-825319 >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> Apache Qpid - AMQP Messaging Implementation >>>>> Project: http://qpid.apache.org >>>>> Use/Interact: mailto:[email protected] >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> Apache Qpid - AMQP Messaging Implementation >>>> Project: http://qpid.apache.org >>>> Use/Interact: mailto:[email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> Apache Qpid - AMQP Messaging Implementation >>> Project: http://qpid.apache.org >>> Use/Interact: mailto:[email protected] >>> >>> >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:[email protected] >> >> > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
