>>>>> "Mark" == Mark J Nelson <Mark.J.Nelson at sun.com> writes:
Mark> It seems like "we can tell that there's an approved RTI for this Mark> bug, but we can't get its synopsis from b.o.o" should result in Mark> passing the rtichk, on the assumption that such RTIs are coming Mark> from inside SWAN, and that an internal pbchk will have validated Mark> the information. I think this will pretty much guarantee putbacks with incorrect comments. Not many (I hope), but definitely some. Mark> For product/category/subcategory tuples that need to be made Mark> visible, this should flag them. But for security bugs, I don't Mark> think we want to put anything outside, including the synopsis, Mark> until the push notification occurs. Hmm. Remote operations are pretty constrained already. I'd want to review the SCM login shell that users get, but I expect it would prevent access to any bug or RTI tables stored on the SCM server. Well, hooks would have access, but we control the hooks. On the other hand, with the current SCM architecture, where everything is served off a central NFS server, I think the RTI and bug information would need to live on the NFS server. So the bug/RTI tables would potentially be visible to something like OpenGrok, which would be bad. I suppose we could stash the CR number and a hash of the synopsis on the SCM server. That would allow for some verification on the server without actually exposing the synopsis. Mark> How important is it that we provide some kind of handshake for Mark> this? Ie an indication that the changegroup has passed pbchk Mark> internally? If I understand the suggestion, it's passing out-of-band information along with the push. I can think of ways to do it, but they're likely to be fragile and/or clumsy. Mark> -- Data may reasonably have a limited lifetime >> It would be better not doing so, such that we have static data for >> test purposes. Mark> Should that need preclude expiration of data, or merely be a Mark> requirement that we provide valid test data? I think we just need valid test data. Mark> The data itself (what we need to validate changeset comments, as Mark> opposed to archival of RTIs) really does have a limited lifetime, Mark> ie from time of RTI approval to time we close the build into which Mark> the changegroup was pushed (to account for followups). This makes sense to me. mike