http://bugs.grommit.com/show_bug.cgi?id=456
------- Comment #2 from richlowe at richlowe.net 2008-04-15 12:09 PDT ------- Beyond this, the comments marked NO_GATE mention that single consolidation, multi-gate RTI's will not be properly checked. A comment with the same tag in Rti.py suggests that wx doesn't support this either, but doesn't go on to compare exactly how and why they fail. I'm told that multi-gate RTIs are only really used (in ON) for sustaining. Integration to Nevada will also have one RTI per-consolidation, and that RTI will not mention sustaining gates for prior releases. Only when a patch is backported may *that* RTI perhaps list on10-patch, on10-feature-patch, on81-patch, and friends. This may mean that in practice the above is not problematic for us in general (as the sustaining gates will stay TeamWare, and I think the associated SUNWonbld should be used with them(?)), so this may not matter at all until there's a Nevada sustaining gate. However, it'd be nice to know how our "not supported" matches the behaviour of a plain wx rtichk, and whether we wish to/can support such an RTI properly. Reading the bits in wx left me vaguely wondering whether webrticli did the right thing in that situation, under the hood, such that the suggestion that wx did not support this is wrong (we specify a gate, and lookup a bug id, my guess at "the right thing", would be that it'd find any RTI mentioning that bug and that gate, patch or otherwise, no matter how many gates were listed in the bug). That maybe our behaviour, too, for all I know. Someone on SWAN, with access to a set of sample RTIs with more than one gate specified needs to test this, and decide whether to fix it. -- Configure bugmail: http://bugs.grommit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
