OpenJDK Bug Tracking Project

[Roger Lewis]

On 3/18/11 1:28 AM, Steve Poole wrote:
> On 16/03/11 22:14, Mike Swingler wrote:
>> On Mar 16, 2011, at 2:39 PM, Dr Andrew John Hughes wrote:
>>
>>> On 16 March 2011 19:14, Phil Race<philip.race at oracle.com>  wrote:
>>>
>>>> On 3/16/2011 11:45 AM, Dr Andrew John Hughes wrote:
>>>>> On 16 March 2011 16:11, Phil Race<philip.race at oracle.com>   wrote:
>>>>>> On 3/16/2011 8:57 AM, Dr Andrew John Hughes wrote:
>>>>>>
>>>>>>> You seem to have omitted the licensing of the bug system.  It 
>>>>>>> should
>>>>>>> be Free Software, in line with the rest of OpenJDK.
>>>>>> This is over-ridden by a need to meet the real requirements. The
>>>>>> licensing
>>>>>> is not
>>>>>> a real requirement. Its a preference. If some non-free software 
>>>>>> fits the
>>>>>> needs better
>>>>>> then so be it. And If Oracle is willing to foot the bill that's 
>>>>>> fine by
>>>>>> me.
>>>>>>
>>>>>> -phil.
>>>>> Nobody said anything about cost.  I'm talking about Free as in 
>>>>> Freedom.
>>>>>
>>>>> For me, this is the overridding factor.  If we're just going to
>>>>> replace one proprietary bug database with another, we may as well 
>>>>> just
>>>>> stick with the one we already have.
>>>> I completely understand what you mean.
>>> Funny, it doesn't sound like it.
>> We may understand your concerns, and simply disagree.
>>
>> The difference is between Free Software being it's own first order 
>> good, or the actual creation of the OpenJDK product itself.
>>
>>>> Its just that its not the overriding
>>>> factor.
>>>> I don't see any necessary connection between being an open source 
>>>> project
>>>> and
>>>> using an open source tool chain.
>>> Clearly this seems to have been true of most people at Sun, leading to
>>> OpenJDK being released in the state it was and IcedTea having to be
>>> created to make it buildable.
>>>
>>>> And it doesn't matter whether the software is free or not. The
>>>> administration of
>>>> it will doubtless not be "free" in any sense.
>>>> The one that's used now isn't a problem because its not open 
>>>> source. Its a
>>>> problem
>>>> because its not accessible.
>>> It matters to me and other people too no doubt.  It's not just about
>>> the source code being available.  Having transparency and working in
>>> the open has an effect on development which leads to a different
>>> product than one which would be developed in a proprietary setting.
>>> We may not need to be able to build our own copy of the database but
>>> we do need to be able to trust the software that's running on the
>>> server and that's impossible with a proprietary solution.  You can
>>> apply all these comments to jcheck too, as I've mentioned on many an
>>> occasion.
>> > From an end-users perspective, there are proprietary bug systems 
>> which may more useable than their open-source counterparts. Trust in 
>> the software to perform it's functions may be possible given access 
>> to it's source, but for most practical purposes, is not actually 
>> verifiable except by domain experts.
>>
>> I agree that the license of the software is a secondary concern 
>> compared to the ability of the software to perform it's required 
>> functions.
>>
>>> You already have a Bugzilla instance set up.  Why not just use it?
>> I am curious about this as well. Does it simply not scale when 
>> confronted with the sheer volume of bugs in the existing Sun database?
> Thats a good point and question -  how many existing bugs are we 
> talking about  and what's the average arrival rate?
Indeed a good question.

As a note, I do not believe that we have ever really shared some of 
these numbers publicly before. I can't say that I aware of any specific 
reason that these numbers were not talked about.

Today, there are approximately 120,000 bugs in Bugtraq (our bug tracking 
system).  We have seen over the last few years that the number of bugs 
is growing at about 7,000 bugs per year. These come from many internal, 
external sources. As it has been stated we want to move all of these 
120,000 bugs into the new system. The feeling is that there is great 
historical knowledge that these bugs provide and loosing them would be a 
shame.

Now for some bigger numbers and a longer explanation.....
There is a second system of bug reports, or as we have called them, 
Incidents. There is some overlap in that 7,000 per year number. These 
are the reports are come in though bugs.sun.com. Historically these had 
gone into a review system, were some were added to Bugtraq, many, many, 
many were found to be duplicates (in those cases some of the data was 
added to Bugtraq) and others were not reproducible and were never added 
to Bugtraq. [This could be an entirely separate thread I am sure.]

Over the last 2 years, it has been a gradual transition, the Incidents 
have been making their way directly into an area within Bugtraq where 
they can be reviewed as well as be seeing within a day or two on 
bugs.sun.com. Some of are calling this a 'triage area'. The intent is to 
have these type of reports to go into the new bug tracking system and 
likely continue to go into a triage area  where they can be reviewed.

One could ask why they need to go into a triage area...... The answer is 
that the numbers are a bit staggering, and many of the reports are not 
complete or duplicates. We currently have over 200,00 Incidents and new 
Incidents are currently submitted at the rate of 18,000 per year. We do 
not plan on moving over the 200,000 Incidents into the new system.

Given those historic numbers, planning for an unknown future number of 
bugs to be added, and building a system that be used for about 10 years, 
we believe that the system should be able to scale up to 1 Million bugs.

-Roger



>> Regards,
>> Mike Swingler
>> Java Engineering
>> Apple Inc.
>>
>