Stephen Hahn <[EMAIL PROTECTED]> writes:
> I've worked through RoundUp and, while it's so general that we could
> make it an ideal candidate, its default configuration is so far from
> ideal that it's not worth pursuing.
>
> As a result of a discussion on pkg-discuss, I stayed up late and have
> a sandbox installation of Bugzilla 3.1.2 installed in a zone in the
> opensolaris.org cage. I'm waiting for the DNS record and the
> firewall changes to be completed, but in the meanwhile, I thought we
> could have a quick discussion on categories, platforms, and states,
> all of which are configurable.
>
> 1. Categorization
>
> Bugzilla has a three level system--classifications, products, and
> components. One possible way to use these is to have two
> classifications: Development and Released. Development then could
> be use products for community groups/projects/consolidations and
> leave the component space to those groups to use.
>
> Released could either copy the current "solaris" categories--or
> not, since I know some consolidations don't like the current
> structure much. I would expect new categories in an open DTS to
> identify their categories in the predecessor DTS, as a courtesy to
> those crossing back and forth.
Agree, though there's a number of cat/subcat things that would be
great to clean up, if that could be done. (the fact the shells are
split between solaris/utility/ and solaris/shell/ being a decent
example there)
> 2. Platforms
>
> 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?)
Do we need that at all?
> 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.)
Can you select more than one in the same bug? Since "Any" wouldn't
seem to cover all the valid possibilities there.
> 3. States
>
> 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.
>
> There are also substates for RESOLVED: { FIXED, INVALID, WONTFIX,
> DUPLICATE, WORKSFORME, MOVED }. There's no equivalent to the
> deferred/no resources available in the current Bugster.
>
I'd very much like to see a far wider (bugster-like) range of bug
states available. Copying Bugster's would, in fact, be a decent start
I think (even if Defer lost its substates).
-- Rich
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
