Alan Burlison wrote: > Mark J. Nelson wrote: > >> - RTIs that may not be visible outside of Sun must use webrti. >> >> - RTIs that may be visible outside of Sun must use openrti. >> > >> - 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.
> In this scheme, it appears that some subset of RTI data will live > outside the firewall, and some subset will live inside the firewall, > correct? The gate hooks which check the RTI before allowing a putback > to complete will be running outside the firewall, once the gate > migrates. There is no mechanism by which they will be able to access > the SWAN-side RTI system. WebRTI also requires access to bug data, and > the same issue exists there as well. Correct. I sent a separate note about the data and mechanisms needed by an outside-the-firewall rtichk to work with inside-the-firewall webrti. I think that just went to scm-migration-dev, I'll forward it. Hopefully that will help clarify what I'm looking for in this thread. and why they're separate. > There are other issues with a 'split brain' approach, such as what > happens if an RTI is incorrectly classified and needs to move. In > general, I don't believe that this sort of inside/outside approach is > practical, the same goes for bug management. The determinism clause above is fundamental in this system. Clearly, it's possible to submit an RTI in either system, and to later find a reason to move it. I think that falls out pretty naturally from the design, but it's probably useful to point it out, because it indicates a need for constant evaluation against the deterministic criteria, rather than only at time of creation/submission. > I think we need to stop trying to find technical fixes for something > that is fundamentally an organisational and managerial problem. I > believe the correct approach is to identify all these sorts of issues, > and then ask for input and guidance from our management chain. Why do you assume that management is giving direction without understanding? What do you think I'm doing here, if it's not "identifying[ing] all these sorts of issues"? I'm explicitly trying to provide the information that our management chain needs, here. The ON gate move will proceed, decoupled from defect tracking and openrti projects. As such, I am NOT taking responsibility for the inside/outside data source problems. My immediate needs are to deal, externally, with internal-only data sources. Perhaps I needed to more explicitly scope this note: I'm not implementing anything here. I'm exploring the next, logical phase of work. We've got the scm migration team tasked with moving the ON gate, the openrti team tasked with developing an open solution for integration approvals, and the cto's office tasked with defect management. I have a suspicion that the order in which they will complete is "ON gate move first, openrti second, and defect tracking a distant third." Understanding what this will look like, and painting a reasonably accurate picture both of the work involved and the pitfalls, is needed by management to evaluate their priorities, and the openrti team to plan their work. --Mark
