So, after we talked about giving a talk, and the specific things people wanted to know, I was kinda brief in my responses.
I figured I'd flesh them out here. There's 4 logical (not necessarily literal) phases here. 1. Get the tools working 2. Get $GATE into mercurial 3. Move $GATE outside. 4. Let people not employed by SMI putback Several meetings ago, we'd tentatively decided that doing #2 and #3 in parallel for the gates we're caring about right now (sfwnv-gate and onnv-gate). Such that 2 and 3 are logically a short loop "migrate and move SFW, migrate and move ON". What it seems we were being asked is about #4. I would state semi-emphatically that #4 is not our problem. How the gates in question wish to handle the possibility of external people putting back is entirely up to them. We need to provide the technology that makes it actually possible (with the exception of the separate projects involved, OpenRTI and DTS), but actually getting to the point it happens is entirely in their court. In my view, #4 also carries undue weight. I think it unlikely it will happen concurrently with #3, and I think any desire to make it do so before its time would be not only misplaced, but frankly foolish. External write access, if done properly, blocks on at least OpenRTI and quite possibly a workable DTS. It is possible, but in my view would be suboptimal, for the sponsor process to continue attempting to paper over those gaps, but I suspect it's unlikely there would be any benefit there as compared to the process operating as now, except a marginally lighter load on the sponsor (which I think in practice would be unlikely to be realized). I guess in summary, the ability for a non-SMI user to putback is merely a matter of the consolidation granting the applicable permission to the user, or users in question. Any question as to when, how or for that matter if they would be willing to do that should be directed to them (Hi jbeck!). -- Rich
