We (the SCM migration team) need to get some input to the openrti folks, and I've been kind of going in circles for a while trying to express our needs clearly.
- We must allow for external CRT Advocates, and must treat them as first class citizens, able to evaluate any incoming RTI from any external contributor or Sun employee. - Some RTIs may never be visible outside of Sun. Examples include security fixes for not-yet-public problems, and RTIs with references to Sun's open source review database and/or legal file index. - Any RTI that MAY be visible outside of Sun MUST be visible outside of Sun. - Information that may not be visible outside of Sun must not leave SWAN. - RTIs that may not be visible outside of Sun must use webrti. - RTIs that may be visible outside of Sun must use openrti. - The "Third Party Souce" questions should be different on openrti than they are on webrti. - The choice of webrti vs openrti should be deterministic, per RTI. - RTIs for patch releases will continue to use webrti internally. - The internal and external (webrti and openrti) tools will share as much common code and user interface as is practical. A possible solution: Clarify and codify the deterministic conditions that affect the choice of internal/webrti vs external/openrti. In each tool, when creating a new, marketing release RTI (name likely to change?), start with a series of questions. As a function of those answers, either allow creation of the RTI, or refer the user to the other system. Example: 1. Do any of the defects covered in this RTI affect security? 2. Is all of the code in this RTI available as open source? 3. Did you use any information considered proprietary or confidential to Sun when you wrote this code? These may not be perfect, but the idea here is for each tool to present an invariant form. Some of the third party source answers only apply within Sun, and any RTI that touches those should be internal. But any RTI that does NOT touch those should be external, which basically means anything covered by an SCA, and anything written by a Sun employee without confidential information or access to closed source. Some potential problem areas: - emancipation efforts, which would require both open and closed pushes, but which should generally involve open RTIs - integration of open source projects covered by an OSR (typically, 3-clause BSD licenses, but others also apply), which should be open, but which have tentacles into Sun's legal processes I think the long term, steady state is going to involve both webrti and openrti, and that we need to get each tool right, along with the heuristics developers use to select a tool. I'm interested in questions, challenges to any of my assumptions, and thoughts on this or any other form of a solution to this problem. An alternative, from a devil's advocate point of view: what if another company wants to contribute, in a way that protects their own corporate information and/or security? Should this whole thing ultimately evolve into "we're ALL simply subject to the SCA, and we all use openrti for every integration to the open gate, regardless of our employment, and we assert as part of filing an RTI that we have done due diligence, following all applicable corporate policies and procedures, regardless of the 'corporation' in question?" --Mark
