RE: [platform-ui-dev] UI-based bug reporting / feature requesting

["leon j breedt" <ljb@xxxxxxxxxxxxxx>]

Hi,

Some update on the progress of this...I've finally gotten around
to starting on this.

How the plugin knows about the
products/priorities/severities/components/platforms
in a particular Bugzilla installation is by way of a metadata file in
XML format. This is a custom format I've come up with since the Bugzilla XML
DTD only defines structures for bugs, not their categorization and all the
other information associated with them which is only available from the
database (or the localconfig file).

Until there is some way to reliably (without error-prone HTML parsing)
query this information, this file will have to be constructed by hand,
or I will have to write a Perl script to generate one for an installation.

A default metadata file will be shipped with the plugin containing
the information for the Eclipse Bugzilla repository.

The Eclipse-specific actions for the plugin use this metadata file to
retrieve the component/product/platform/os information.

I've completed the parsing for this file, it gets parsed into an
IBugRepository instance, which contains all the relevant product/component
info, and also started on the UI for the reporting.

I'm at the point now where I want to streamline the UI, and I'm wondering
which approach people will find the most workable:

    (1) One page like the Bugzilla bug reporting page containing
        all the fields required for a bug, with defaults filled
        in where possible for the Eclipse build / platform / JVM
information.
    (2) Two or three wizard pages that break it down into more
        manageable chunks:
            - categorization of the bug (with info about the various
categories)
            - more detail (description, how-to-reproduce, stack traces)
            - more information about the reporter's environment

Or do you think this should be a preference for beginner user and
power user mode...Since I'd really like to provide as much information
as possible to the end user about what the various fields mean and
what the recommended values should be, so that the resultant reports
are useful. On the other hand, I don't want to get in people's way...

Also, how would be the best way for other plugins to access this
functionality, and provide some defaults for the pages...A
method on BugzillaPlugin, providing an already initialized EclipseBugReport
(which contains all the information for the bug)?

Comments?
Leon.

--
ljb@xxxxxxxxxxxxxx :: +27.82.789.0445
>> don't play in the kiln.