James Carlson wrote:
Stephen Hahn writes:
descriptions (E7). (I'm also curious about operational requirements
about offering the entire community bug corpus, but that's probably
separate.)
I don't think it's separate from the DTS requirements at all.
I see offering the raw database itself as a fundamental issue of
openness. In the same way that we allow others to create independent
repositories of the OpenSolaris code itself, and thus cover for any
possible (however unlikely) failure on the part of Sun to deliver in
the future, we must also provide equivalent access to defect
tracking. The code and the bug database are not independent.
Doing that while maintaining the confidentiality aspects could be complex,
depending on backend storage, but I think it's a reasonable requirement too.
I do _not_ consider it an acceptable outcome if the tracking system (I
hesitate on the word 'defect', as many issues are RFEs) provides only
mediated access to the repository, even if that's somehow done through
some neutral third party.
If only for backup purposes, I agree.
* Upstream/downstream. The OpenSolaris program is but one more step
in a progression from an operating environment composed entirely
of components created and/or maintained by a single organization
to one constructed from a wide variety of components originating
from multiple organizations and individuals. Where those
components have defect state tracked in a DTS, it would be
economically beneficial to have that state represented in the DTS
used for the operating environment effort.
I'm having trouble parsing that. I *think* you're saying that when we
have non-OpenSolaris components (aka "freeware") bundled with Solaris,
and we track defects using the OpenSolaris tool, we need some way of
making sure that we're not just duplicating the effort of some other
system.
I read it to mean linking an issue $HERE to an issue $THERE for various
values of both. I'm still not convinced this functionality need be anything
more than a simple pointer to $THERE, however.
Is that what this section is about? Or is it trying to say something
else?
Unfortunately, migrations from one DTS to another are expensive, at
least in the experience of the Solaris/OpenSolaris bug corpus. A
realistic idealized outcome would be three-phased, after the
candidate DTS is selected and implemented:
It might be good to provide some idea of what sort of timeline is
needed to accomplish a goal like this -- so that others reading the
document have some idea of what to expect (and what not to expect).
I very strongly agree with that.
My guess would be that Phase 1 could start right after getting the new
system running -- perhaps as soon as a few months. Phase 2 would take
a more substantial switch-over and coordination with other groups that
are not well-represented in OpenSolaris yet. Perhaps a year or so.
phase 2 specifies that only bugs present in the new DTS would integrate, but
bugs could be filed to the old one. I'm not sure of the practical benefits
here, given to integrate any bug would have to be copied to the new DTS.
Where's the benefit? (I'm obviously missing something, I just can't tell what)
Phase 3 is _much_ longer term. Perhaps not until S10 itself goes EOL
-- years from now (especially so with no target S11 release).
Messaging and notification is expected to be delivered as
electronic mail; additional protocols must be optional.
I'm not sure what "must be optional" means in this context; it seems
like a terminology conflict. I think this means "may be present, and
should be possible, but are not strictly required by this document."
I wasn't sure if it related to requirements or operation. "Should be
possible, but must not be mandatory"?
E6. Standard operations and transactions
The candidate DTS is expected to support rename and deletion
transactions at the file and directory levels. Note that a
history-preserving copy operation, followed by a delete
operation, may be considered equivalent to a rename.
What are the "file" and "directory" levels? Up to this point, we were
talking about defect tracking, not source code control.
I assume "directory" == cat/subcat, and "file" == issue, but it's equally
likely to be a paste error.
- create defect
- modify defect content
- modify defect metadata
- place defect in resolved state
That might be incomplete. We also have closed-but-not-resolved
states, such as "not a defect," and we have states that refer to what
are essentially management issues (defer, fix available, unverified,
and so on).
I'm unclear on what's actually _required_ for OpenSolaris problem
tracking and what bugster just happens to support. (In many cases,
bugster supports things that we don't seem to care about ... in
others, it constrains how we think about the problem.)
One of the problems I see here is that in talking about a tracking
system, we're inherently also talking about our process for filing,
evaluating, and fixing bugs and missing features in the system. I'm
not sure if there's anyone from RPE on tools-discuss ... if not, we
should get someone from that group to look this over.
- restore defect from resolved to unresolved state
- associate defect with external resource
- associate defect with another DTS-tracked defect
- associate defect with keyword/text label
- change defect category
We probably need a backing document that describes what some of these
things do, so that we're all talking about the same thing. For
instance, "keywords" (in the bugster sense) are not what humans would
ordinarily think of as "keywords." (Instead, they're actually more
like sorting tags or attributes used for associating groups of
otherwise unrelated bugs together -- e.g., "bugs essential for the Foo
project.")
In addition to the initial evaluator list, Bugster associates
categories (actually subcategories) with responsible managers. The
theory is that the manager is then responsible for making sure that an
engineer is eventually assigned. Does the same sort of thing exist
here (who are the "technology owners?" -- are they the community
groups?), or do we give up on that concept?
I think that's a concept that doesn't translate well at all.
Bugster keeps information about "severity" (the damage caused by the
problem, as evaluated by the submitter) and the "priority" (the
importance of fixing the problem as jointly determined by interested
parties). Do these things matter?
I think so yes, it constantly bugs me that I can't see those fields via
bugs.opensolaris.org, anyway.
E7. Scalability
The candidate DTS must have one or more deployment
methods that allow the DTS to carry large query loads. The
latency between a defect report update and its accessibility to
be queried must be documented for such scenarios.
I'd suggest adding the ability to track problems in private projects
as one of the requirements.
Yes, I agree there too depending on precise values "private" (be it
invisible to any but a select group, or only meaningful to a select group,
both are important).
A common problem is that projects need to track defects well before
integration. This means that the tracking system must allow for more
flexible category naming (allowing those projects to come and go more
frequently than would otherwise occur), more flexible handling of
release numbering or naming (often just date stamps or serial
numbers), and some way to move any remaining unresolved (presumably
low-priority) bugs and RFEs in bulk into the "mainstream" once the
project integrates.
That brings up another key requirement: bulk updates. We absolutely
need an interface that allows automated and bulk-type updates to be
performed on the database. These are common for gatekeeping, and
sometimes used in other contexts. Forcing all updates to be one-at-a-
time and via some web or java interface is not an option.
The expected set of meaningful operations for performance evaluation
are:
- unresolved defects query against a product or category,
- defect query by keyword or other text label,
- defects resolved by a single responsible engineer,
"Resolved against a particular release" is another fairly important
operation, at least for support folks.
"Full search for text content (in any field)" is something I tend to do with
reasonable frequency (often but not always qualified by at least category,
if not subcategory), it's also one of the more abusive searches to put the
thing through.
-- Rich
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
