On Wed, Oct 17, 2007 at 12:36:18PM -0700, Stephen Hahn wrote:
> The default fields are OS and Hardware. OS is { All, Windows, Mac
> OS, Linux, Other }. It seems like adding OpenSolaris and Solaris
> would be the minimum, but there might be other choices to make
> here. (Like the host VM, possibly. Or is that hardware?)
>
> Hardware defaults to { All, PC, Macintosh, Other }. This seems
> unhelpful. I was playing around with { ANY/Generic, i86pc/i386,
> i86pc/amd64, SPARC/sun4u, SPARC/sun4v, Other }. (I guess an
> i86xpv field might be needed now.)
I can imagine two reasonable fates for the OS field: elimination and
conversion to a list of distributions. { Solaris, OpenSolaris }
doesn't seem to make any sense since the two are not peers. Keeping
the others would be useful only for interop bugs. What did you have
in mind here?
For hardware, I could go with either your suggestion or the more
general { x86, sparc, all } suggestion.
In any case, I see these acting like the release and hardware fields
in an SR: it doesn't mean it's unique to the software in question but
merely indicates where the problem was observed. Was that your
intent? Is this how people expect the field to be used, or is it
often used to imply diagnosis?
> Bugzilla defines the bug states as { UNCONFIRMED, NEW, ASSIGNED,
> REOPENED, RESOLVED, VERIFIED, CLOSED }. It is reasonably easy to
> add new states, and to restrict which state transitions to and from
> a new state are permitted. In current Bugster, we have useful
> states where the problem is understood and where the fix is in
> progress.
Is it also possible to require that certain fields (e.g.,
RE/Assigned-To) be filled in or not filled in when entering a state?
--
Keith M Wesolowski "Sir, we're surrounded!"
FishWorks "Excellent; we can attack in any direction!"
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
