OpenJDK bug database: DRAFT Developer Workflow
georges.saab at oracle.com
Sat Dec 17 23:18:38 PST 2011
Hi Volker --
Please see inline
On 16 dec 2011, at 16:18, Volker Simonis wrote:
> 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.
Nothing to 'consider', for me it is a requirement that the new system
allow more of the OpenJDK community than just those employed by Oracle
to create a bug!
> 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.
And by the same token, for somebody at Oracle to spend time opening
a bug report so someone else can check in their fix (not to mention having
to do checking testing for them and in some cases make fixes to the fixes) is
if not annoying, certainly not exciting, especially when they have a long list
of bugs they need to be working on themselves!
> On Fri, Dec 16, 2011 at 8:53 PM, Iris Clark <iris.clark at oracle.com> wrote:
>>>> 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.
More information about the discuss