From Genunix
comment: RL: defect.opensolaris.org is not even currently a beta,
fervent desire aside. I happen to have code that would support
its use, but I have no plan to integrate it currently.
The block on external committers to most places, right now, is
that bugs in d.o.o don't count for (ON, SFW, etc, etc). Only the
various project gates making use of it.
Sorry, let me expand upon that somewhat. I don't want the comment
checks to accept bugs from defect.opensolaris.org as long as
that's not an absolutely correct thing to do.
While for a change to slim_install or pkg-gate it would be valid,
it's absolutely wrong for others. The other alternative I can
think of (baking that knowledge into the code) is untenable, I
think.
If there's another way to go about it, I'm open to suggestions.
comment: SCH: (I may have missed some context on what the checks are
doing for bug lookups; apologies if the following is redundant.)
Why couldn't we define a syntax for defect. bugs, like "[0-9]+o",
and match/check both that and the "[1-9][0]9]{5}" pattern for
Bugster?
I agree that the tools shouldn't know about any specific
gates/projects.
comment: JC: That's exactly what I was asking for.
Agreed. I think Rich's real concern here is that
"defect.opensolaris.org" is somehow "not official yet."
My point of view is that it's only "not official" because we're
continuing to treat it that way. Everything else in terms of due
diligence (similar to the choice of Mercurial) has already been
done.
comment: SCH: Yes, and various Sun-specific steps we took during the
DSCM change have been completed/accepted for this change. So, if
it's any reassurance, it's getting to be more and more official.
But I guess what's being asked for is a complete picture, which I
don't personally have (beyond believing that we're in the two
systems phase mentioned in the DTS requirements).
comment: JC: More concretely, I think Rich is worried about what
happens to ON and SFW gatelings who attempt to file an RTI based
on a d.o.o entry. It'll "fail" in that webrti won't accept the
defect number as valid, but "hg nits" and "hg pbchk" will blindly
allow those numbers.
I think that's actually a good state to be in. I suppose you
could have a "are we allowed to use d.o.o yet?" flag somewhere,
but I'd rather not. It just makes the external webrti application
harder to deploy -- because users will be annoyed by the Cadmium
commands.
In other words, until webrti is finally fixed, you're still on the
hook to do whatever is right by your local gate. Cadmium (and wx
before it) can _help_ you do that, but they're hardly infallible.
Thus, I'd prefer to build in the d.o.o support as soon as
practical.
comment: RL: Well, the best I can say is "Nobody actually told me
that until just now". If that's the case, I'm fine with this.
I'm taking that to mean that the C-Teams and such are happy with
bugs filed in d.o.o and not bugster being integrated into their
various consolidations, etc, etc, etc.
My argument was based on the information I had, which was us not
yet being at that point.
Either way, if either you or Jim file an RFE (on grommit, I
assume), we'll get to it as priorities dictate no doubt.
comment: JC: It likely doesn't mean that *until* the webrti bits
catch up. But someone surely must go first. ;-}
I'll file an RFE on grommit. I think the priority should be
normal, and the target should probably be post-tools-putback. If
it happens before that time, I'd be thrilled, but it's only really
required for the external webrti tool.
comment: RL: (in response to JC) Right, if folks say "We'll accept
bugs in defect.opensolaris.org in putback comments", this is
trivial, and we can do it. Nobody said that yet.
Last I knew, however, work was still ongoing (or at least being
discussed), regarding making d.o.o the one true system (maybe I'm
wrong), and that it should only be used for in-development work,
and indiana (to avoid the case of running two systems in parallel,
chaos for users, and developers this is, not tools).
If that's not the case, I'm fine with us doing it, at appropriate
priority (and as I said, I have some of the code to do it, too).
comment: RL: (in response to SCH) I spoke to comay some about this
yesterday, though with no real conclusion. One thing that occured
to me in talking to him, is that while the dev tools can't know
which gates is which, and what is acceptable to whom, the gate
hooks quite clearly can, so at least in concept the tools can say
Ok to a d.o.o ID, but ON and SFW refuse them. I'm still not
convinced that's a great idea to do now.
With your idea above, the same would be necessary, as ON and
friends would still need to know that [0-9]+o or whatever pattern
was used was incorrect for them.
