[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