So the directive is to move the ON gate without waiting for or
coordinating with the RTI or defect tracking folks.
While I think that the whole is much greater than the sum of the parts,
I also agree that herein lies our greatest (only, perhaps) chance of
getting this ("open development") done.
So before I start laying out the rti-related tasks, I wanted to get a
sanity check on where my thoughts have taken me:
- We need, in this phase, to interact ONLY with webrti, ignoring openrti
- We will NOT solve the "how to query webrti from opensolaris" problem
- We need to validate both ARC case references and bugids against
approved RTIs
- We (the SCM team) will need to implement something along the lines of
the arc database (flat file, really) push and arc.py to allow this to
work on opensolaris.org, with some differences:
-- The data push will need to be synchronous, rather than asynchronous
like the ARC data. That's because the time delay from RTI approval to
push is often negligible. Mechanism for triggering the push is TBD,
could be e-mail, could be done by webrti, need to work with Larry to
figure it out.
-- Data may reasonably have a limited lifetime
-- We should define the format based on our intended usage
-- We'll want to consider what we do for multiple consolidations and
target gates. Might be reasonable to only keep "approved for onnv-gate"
RTI data.
I'm thinking that we (the SCM team) need to take this on as part of
moving the gate. Further, I suspect that whatever we do will likely
live for longer than we might guess; see my next note rambling about
webrti/openrti boundaries.
--Mark
