Richard Lowe writes:
> > I think we do have to have a way to maintain referential integrity
> > between the open bug database and private data stores, but I don't
> > think we can avoid the problem merely by hiding away the raw (open)
> > repository.
> 
> True, I was referring to (I think) the initial draft mandating a mechanism 
> to store confidential information, the ability to provide raw access while 
> excluding said information is just one aspect of the complexity there.

OK.  My point is just that adding a raw access requirement doesn't
appear (to me) to create any new burden in this area.  There don't
seem to be any _reasonable_ solutions that would preclude raw access,
and yet handle the confidential restrictions just fine.

> > It won't switch in a day.
> 
> Yes, it's the fact that any bug filed in the wrong place would have to be 
> copied out that's throwing me.  If that's the case, why allow them to be 
> filed incorrectly in the first place?

"Allow" is perhaps a too-strong word.  We're talking about changing
the direction of a rather large sea-going vessel, so it doesn't seem
unreasonable to me to suppose that changing the rules one bit at a
time (rather than throwing a big switch) will be less likely to result
in mass confusion.

> > This issue has mapped into Bugster as the "responsible manager," and I
> > completely agree that the identical concept is without meaning for
> > OpenSolaris, but I suspect that there's some equivalent that would be
> > just as valuable -- such as "owning community group."
> 
> Yes, I don't think that consumes Sun's use of the field however (at least, 
> as I understand the use), so the information currently stored there would 
> probably need to exist internal to Sun.  I would also wonder whether in the 
> scenario above, IE and RM wouldn't often be the same individual or group.

They're not usually the same.

"IE" usually maps to someone technical who can look at the problem and
figure out whether the bug is complete and is filed in roughly the
right category.

"RM" maps to someone you can talk to (or yell at, if necessary) to get
a bug or RFE prioritized as needed.  This is the authority path,
rather than the technical path.

I don't know who "IE" might be in the OpenSolaris world (except
perhaps just a list of Core Contributors), but I think the common use
of "RM" in Solaris corresponds roughly to "community."

> > You're right that I wasn't clear on that.  I'm not advocating for
> > closed project development, or any means to support it.  Unlike closed
> > ARC cases, I don't see a need for OpenSolaris to provide any special
> > bug tracking resources for closed projects.  The two issues are pretty
> > different.
> 
> Tell that to the various projects with hidden (or See Comments'd, or 
> similar) bugs...
> 
> I can accept they're wrong (and I believe they're wrong, too), but they 
> appear to disagree.

I think there are many issues here:

  - Habits.  Old habits (especially bad ones) die hard.

  - Lack of understanding.  Not everyone realizes that comments are
    hidden or why hiding things is necessarily a bad thing.  (In some
    areas, I suspect that anything containing references to code or
    variable names will trigger an impulse to hide.)

  - Spurious claims of privacy.  Some feel that bug reports -- even
    those focused on the system itself -- always reveal too much about
    a given customer, or that customers will be annoyed to see their
    problems given public airing (even without their name on it).

  - Lack of tool flexibility.  We have just "description," "comments,"
    and "evaluation" to play with.  Sometimes, there's information
    that doesn't fit into the first or last of those, so what are you
    to do?  Put it in the wrong place just so that others can see it?
    That's giving in to the tool defects.

  - Simple mistakes.

I don't think there's a single answer, so it'll take time to repair.
I think having a new and separate system will help by creating some
useful disruption, though.

-- 
James Carlson, Solaris Networking              <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org

Reply via email to