I added Val and Alan, because it helps scope the other conversation.
So please use this note for replies, or add them manually. Thanks.
My responses to Rich inline below.
--Mark
Richard Lowe wrote:
> "Mark J. Nelson" <Mark.J.Nelson at Sun.COM> writes:
>
>> 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
>
> Yes.
Sorry that this info was missing from the other thread.
>> - We will NOT solve the "how to query webrti from opensolaris" problem
>
> Well, you're kind of doing that below.
Only "kind of." I wrote "query webrti from opensolaris" to imply a pull
mechanism, and what I'm describing below is a push. I further meant for
"query" to imply "access the database," which may well contain lots of
information that should not leave SWAN.
So the real point of this was to scope the problem to identifying the
information needed by rtichk, and pushing that in a way that protects
the rest.
>> - We need to validate both ARC case references and bugids against
>> approved RTIs
>
> Yes.
Anything else?
Comment checking already involves validation of synopses and case titles
against b.o.o and arc.py, respectively. I don't want to conflate that
here, so this implies a class of bugs that won't be verifiable externally.
It seems like "we can tell that there's an approved RTI for this bug,
but we can't get its synopsis from b.o.o" should result in passing the
rtichk, on the assumption that such RTIs are coming from inside SWAN,
and that an internal pbchk will have validated the information.
For product/category/subcategory tuples that need to be made visible,
this should flag them. But for security bugs, I don't think we want to
put anything outside, including the synopsis, until the push
notification occurs.
How important is it that we provide some kind of handshake for this? Ie
an indication that the changegroup has passed pbchk internally?
>> - 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:
>
> Seemingly.
>
>> -- 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.
>
> Yes.
>
>> -- Data may reasonably have a limited lifetime
>
> It would be better not doing so, such that we have static data for
> test purposes.
Should that need preclude expiration of data, or merely be a requirement
that we provide valid test data? I don't want to incorporate archival
requirements here, because this stuff really lives in webrti, internally.
>> -- We should define the format based on our intended usage
>
> Yes.
>
>> -- 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.
>
> We need the data from any gate with opensolaris related plans, or the
> ability to add to the set of data easily (ON, SFW, X seem like
> opensolaris citizens that may need it at some point).
I'm slightly happier with designing this to provide "the ability to add
to the set of data easily," rather than providing it off the bat. But I
don't feel strongly either way.
>> 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.
>
> I suspect it will likely live forever, in some form.
I completely agree, especially given the tie-in with the other thread,
regarding webrti/openrti. But that's explicitly talking about continued
use of webrti, and the resulting need for this mechanism.
The data itself (what we need to validate changeset comments, as opposed
to archival of RTIs) really does have a limited lifetime, ie from time
of RTI approval to time we close the build into which the changegroup
was pushed (to account for followups).
--Mark
