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

Joshua Bell josh at lindenlab.com
Wed Jan 9 18:44:10 PST 2008


Mike Monkowski wrote:
> 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.
We internally track this by tagging the items with an actual Fix Version 
only at the point where the change has merged into the trunk - which is 
the soonest point you can predict what version it will be in. I do this 
by tracking the branches as they go in and doing bulk updates. 
Therefore, Status = Resolved, Resolution = Fixed, Fix Version = 1.19.0 
indicates that not only is it fixed but it's merged into the trunk. We'd 
create a Version 1.19.1 as soon as 1.19.0 is frozen (branched) so that 
the next fixes to merge into the trunk can be marked appropriately.

Ideally we would sweep through the JIRAs that have PJIRA counterparts 
and do the same thing. We're still trying to get tools/processes into 
place for this, and additional people to help. There's also the overhead 
that suddenly 1.19.1 appears in PJIRA before we're even ready to really 
start talking in detail about 1.19.0, so suddenly a gazillion questions 
come our way. But that's why this is fun. :)

Joshua



More information about the SLDev mailing list