OpenJDK bug database: DRAFT Developer Workflow

[Volker Simonis]

Hi Iris, Georges,

OK, I see the problem with "end user" bugs if these are really
"millions" per year.

But than please seriously consider giving any OpenJDK Participant
(anybody who subscribed to an OpenJDK mailing list) or at least any
OpenJDK Contributor (Participants who have signed the OCA) the right
to directly submit bugs into the "real" bug system. I don't think that
there will be millions of these people (the current list of Oracle
Contributor Agreement signatories at
http://www.oracle.com/technetwork/community/oca-486395.html currently
lists ~1400 signatories) and I don't suppose they will submit more
than some hundreds or perhaps thousands of bugs. On the other hand if
somebody signed the OCA I think this is a strong indication that he
seriously  wants to contribute to the OpenJDK and I think most of the
reports from these people will be high quality bug reports.

There's nothing more annoying for a developer who has identified and
fixed a bug in the OpenJDK than first going trough the process of
asking sombody at Oracle to please open a "real" bug report for the
issue before he can actually file an "official" request for review
with a valid bug ID.

Regards,
Volker


On Fri, Dec 16, 2011 at 8:53 PM, Iris Clark <iris.clark at oracle.com> wrote:
> Hi!
>
>> > I personally don't think that two parallel JIRA instances will be
>> > particularly useful. They will be just a constant cause of confusion.
>> > Because eventually you'd have to transfer bugs from the "end-user" bug
>> > system to the "real" bug system. And even if you'd somehow manage to
>> > keep the bug ids unique between the two systems, you would still have
>> > two systems with all the drawbacks:
>> > - which system to search (before entering a new bug)
>> > - in which system to track the bug
>> > - you'll have to keep the bug content in sync between the two systems
>> > (otherwise, if you just move the bug from one system to the other,
>> > links to the original bug won't be valid any more)
>> >
>> > So please stick to one system if possible. You could for example just
>> > introduce a new state "UserBug" in the workflow which comes just
>> > before "Dispatched".
>>
>> Currently there is a system (web-bugs) for handling bug reports from end
>> users.  Most of these are not developers.  Most have no idea what information
>> is needed to track down an issue.  There are millions of these reports that
>> come in each year.  Many need more info. Many are duplicates.  Many are not
>> even bugs.
>>
>> Every once in a while something really really important comes through this
>> channel, however.
>>
>> IMHO - we want end users to be able to file reports, but keep them separate
>> from the database used by development.  We want the OpenJDK community to be
>> able to help triage and respond so that it is possible to scale the way we
>> deal with these and not miss real and important reports -- but get these
>> swiftly and smoothly transitioned to the development JIRA project.
>
> While I understand the desire to have a single JIRA Project for all bugs
> regardless of their source, I'm not confident that that is very feasible given
> the nature of typical end-user-submitted bugs.  Even with the hints we
> provide during submission (i.e. explicit request for "Steps to reproduce",
> "Expected Result", "Actual Result", etc.), we still get problematic reports
> as Georges indicates above.
>
> I don't think that one or two statuses tacked on to the beginning of the
> Developer workflow will be sufficient.  I'm also concerned that by having all
> of these end-user bugs within the same JIRA Project, we'll introduce a
> degradation in our ability to manage the main developer workload.
>
> Thanks,
> iris