Update on bug system for OpenJDK (web-discuss)

[Roger Lewis]

>> I agree - but that needs to be handled by the "first tier" system (as 
>> is mostly done today). I don't want to be the one who has to wade 
>> through these issues and identify them - by the time a bug gets into 
>> bugster today it "should" have reasonable merit and shouldn't be a 
>> duplicate.
> It's not clear to me that we need this filtering, at least not 
> initially. I can't imagine end-users seeking out the OpenJDK bug 
> database, unless they have a message dialog or error log that tells 
> them to go there. So if consumers could be directed somewhere else 
> then there's a good chance that most of the bugs will come from 
> developers that want to help by reporting a bug or maybe contributing 
> a fix. Sure, we'll still get some poor quality bug reports but that is 
> par for the course. I would suggest it would be better to see how it 
> goes before deciding to setup a quarantine area. Another thing is that 
> one would hope that an open bug database will encourage more 
> volunteers to help, and so there should be more eyes on these bug 
> reports (and so one would hope that the poor reports will be closed 
> quickly).
Filtering at this level, to some degree, can be achieved by providing an 
appropriate reporting path to users being targeted. Not all submission 
paths suit all users.

For Java SE as it is today, all bug reporting occurs on 
bugreport.sun.com, but the depending in the context you see this domain, 
the page you are directed to is intended to obtain the information that 
is necessary to make a useful report, and present the reporters with 
questions that they are likely able to answer. Also, the resulting 
location of those reports can vary depending on the path.

    - For end users, on java.com, the page they are directed to:
    http://bugreport.sun.com/bugreport/main.jsp


    - Java Developers/IT administrators/'more advanced end users', and
    others, who find this next link in ReadMe's, on bugs.sun.com,
    documentation, and elsewhere are provided with :
    http://bugreport.sun.com/bugreport/
    Within that reporting path, the questions can vary for bug vs RFEs
    and in some cases vary on the 'product' the reporter selects.
    This path 'loosely' requires fields like 'java -version', a test
    case, steps to reproduce, what you expected to happen and what
    really happens. This results in a report that looks like this, where
    all of the output of those fields are 'stuffed' into a description
    field in BugTraq:
    http://bugs.sun.com/view_bug.do?bug_id=6550655

    - The most commonly used reporting URL (around 450 reports a month)
    is presented to users when they experience a HotSpot crash:
    http://java.sun.com/webapps/bugreport/crash.jsp which redirects to
    http://bugreport.sun.com/bugreport/crash.jsp
    In this reporting path there is an effort made to separate out end
    users who have experienced a crash vs. those who are developers who
    have the ability to diagnose and report a full and complete 'bug
    report'.

    - For those who can access BugTraq, they are able to create bug
    reports that do no go into a 'triage' area and are not forced to go
    through the lengthy set of questions.


This set of paths is not perfect by any means. Overtime, with adding and 
improving paths, we have seen bug quality rise significantly over the 
single text box that appeared on what was the original reporting page: 
http://java.sun.com/cgi-bin/bugreport.cgi

Given the vast user base of Java being able to provide the right users 
with an appropriate and customizable path is essential.

Anonymous reporting into a non-triage area, should not be allowed, as 
those paths should provide a less structured reporting process. In some 
cases, for some, like OpenJDK contributors, there should be only a 
minimum set of data necessary to create a report.

>
>> :
>>
>> I was with you right up to the last sentence. Having to register 
>> would dissuade some users from bothering to report non-bugs (but it 
>> may also dissuade them from submitting real bugs!). There needs to be 
>> a system where a report can easily be entered by anyone, but that 
>> report needs to be pre-processed before being accepted as a bug (in 
>> todays terms it gets submitted as an "incident", processed and if 
>> deemed suitable then a bug is created in bugster).
> I don't know how many projects allow bug reports to be submitted 
> anonymously. At least with bugs.openjdk.java.net you have to login, 
> and same thing for other bugzillas that I've submitted bugs to. With 
> the legacy bugs.sun.com then you also have to fill out a form with 
> your details. One useful thing about requiring a submitter to login is 
> that there is contact address, useful if follow-up is required to 
> duplicate or verify a bug.
Bug reporting on bugs.sun.com is somewhat anonymous...... Which has lead 
to many hallway discussions as to whether it should be allowed. In the 
end is what is there today. An email address is mandatory, that email 
address is only validated in that is matches a 
name at domain.toplevelDomain format. The thought has been that people do 
not want to create a new account in a system to report a bug, and we 
want to make the process easy enough to not scare off those who do not 
want to go through that step.  Though having a login, in some submission 
paths, would be nice, it was unfortunately never implemented on 
bugs.sun.com.

Most reporters provide valid addresses, though we do see fake email 
addresses, that bounce.  Often, even if they have a corporate address, 
say name at oracle.com, they will use their personal, or a 
name-spam at domain.com address.

-Roger