[META] What's a RC? was: [sldev] Roadmap: 1.19.0 Viewer

Mike Monkowski monkowsk at watson.ibm.com
Wed Jan 9 17:01:15 PST 2008


So it looks like the JIRA ought to have another state "passed QA" when 
foo gets merged into the trunk.  This would give statistics for how long 
fixes spend in QA and how long from then to getting into a RC.  The time 
period from "fixed internally" to incorporation in a RC depends a lot on 
how long the previous branch of RCs take to go live and where in that 
cycle the QA completes.  And knowing that a patch will get into the next 
RC branch is more satisfying than knowing that it's "fixed" but somehow 
still languishing while users suffer.

Mike


Kelly Linden wrote:
> Tofu Linden wrote:
> 
>> Mike Monkowski wrote:
>> > OK, that makes more sense.
>> >
>> > Now a question regarding "Fixed Internally" on the JIRA.  If I
>> > understand correcly, some bug fixes get into RC2, RC3, and so forth,
>> > depending on their severity and complexity, but all remaining internal
>> > fixes should show up in the next RC1.  Correct?
>>
>> No, any remaining fixes might still be arbitrarily far from release
>> depending on where their respective branches are in the QA pipeline.
>>
>> -Tofu
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html
> 
> This is best shown with a picture, attached to this message!  It is of 
> course overly simplified.  This diagram *just* shows how a fix that goes 
> in while 1.18.6 RCx is out may still not make it into 1.19.0 and is not 
> a complete picture at all.  Where I marked 'fix foo submitted' is 
> actually the point it will often get marked as 'fixed internally' or 
> 'fix pending', and when it starts going through internal QA.
> 
> The flow is left to right, sorry for the lack of arrows, this was a 
> quick mock up.


More information about the SLDev mailing list