[Fwd: Re: Request for comments: New Bugzilla-based contribution process]

Mon Feb 23 18:31:39 UTC 2009

Roger,

 > bugs.sun.com 'should' be a reflection of Butraq, off by at most 24
 > hours.In this case it appears that this bug has not been updated since
 > BT was last updated. Which is why they do not accurately reflect
 > Bugtraq.

So how do people outside Sun figure if this status applies to the JDK7 
or 6uX subCR from the bugs.sun.com page?  It's just "a bug" on 
bugs.sun.com.  bugs.sun.com says this was reported against b21, which 
from Bugtraq shows it's for the JDK7 version.  But this has *NEVER* been 
state "Fix available" in JDK7, only "Fix in progress."

For the 6uX version, it did progress to that state:

8-Fix Available	2009-01-21 22:00:49 GMT+00:00	xxx at sun.com
10-Fix Delivered 2009-01-30 22:46:17 GMT+00:00	yyy at sun.com

But there's no way for folks to know which version the state applies to. 
  I only know because I have access to bugster.

Brad

Roger Lewis wrote:
> Ramsci
> 
> Can you refresh bug 6622432. It is being looked at by a number of groups 
> and seems to be out of date. The data is Bugtraq (State and Integrated 
> fields) is out of sync.
> 
> -Roger
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: Request for comments: New Bugzilla-based contribution process
> From:
> Brad Wetmore <Bradford.Wetmore at Sun.COM>
> Date:
> Mon, 23 Feb 2009 10:42:55 -0600
> To:
> Volker Simonis <volker.simonis at gmail.com>
> 
> To:
> Volker Simonis <volker.simonis at gmail.com>
> CC:
> Mark Reinhold <mr at sun.com>, discuss at openjdk.java.net, Roger Lewis 
> <Roger.Lewis at Sun.COM>
> 
> 
> 
> I feel your pain.
> 
> Roger, Mark or someone more familiar with Bugtraq, perhaps you know the 
> answer to this?
> 
> So that the external folks can follow along, we have several states in 
> Bugtraq (Sun's internal bug tracking system):
> 
>     Fix In Progress - developer is working on fix.
>     Fix Available   - Fix is available, isn't in product workspace yet.
>     Fix Delivered   - Fix is in product workspace.
> 
> Bug 6622432 is tracked in bugster as a MR (Multiple Release Bug).  The 
> SR (Service Request) against one of the future Sun JDK6 update releases 
> is marked as "Fix Delivered".  The SR against 7 is marked "Fix In 
> Progress".  There is no SR currently for OpenJDK6.
> 
> The external page:
> 
>     http://bugs.sun.com/view_bug.do?bug_id=6622432
> 
> does not mention which release this is against, and apparently splits 
> the middle by reporting "Fix available".  According to the Bugtraq log 
> history, this has never been "Fixed available" in 7.
> 
> So, what (and why) is bugs.sun.com actually reporting?
> 
> Once we do most bug tracking on Bugzilla, hopefully this will go away.
> 
> Brad
> 
> 
> Volker Simonis wrote:
>> Sorry for cross-posting, but I think the two threads are related and
>> this post belongs into both of them:
>>
>> Just to name a current issue and demonstrate how complicated it may be
>> to follow the development process, lets consider Bug ID: 6622432 (RFE:
>> Performance improvements to java.math.BigDecimal):
>>
>> On the mailing lists, there was a Request for review:
>>
>> http://www.mail-archive.com/core-libs-dev@openjdk.java.net/msg01095.html
>> http://webrev.invokedynamic.info/xiaobin.lu/6622432/
>>
>> But I couldn't see a changeset for the bug. So apparently it is not in
>> any of the OpenJDK 7 repositories (at least I couldn't find it).
>>
>> On the other hand, the Bug says "State, 8-Fix Available". Brad wrote
>> "When the fix is put into one of the gates, the fix goes to "fix
>> available" in bugtraq.  It's the gatekeepers who mark as Fix
>> Delivered." So apparently, the change went into a closed "gate".
>>
>> I would guess it could be the "JDK6 RE build" Mercurial repository
>> mentioned by James Melvin in another thread
>> (http://www.nabble.com/How-to-host-HS14-stable--%28Was%3A-RFC%3A-Change-name-of-default-HotSpot-to-%27default%27%29-tp22053363p22053363.html) 
>>
>> because the list of fixed bugs for JDK 6u14 b01
>> (http://download.java.net/jdk6/6u14/promoted/b01/changes/JDK6u14.list.html) 
>>
>> lists 6622432 as fixed. But this is in contradiction to the status of
>> the bug which is  "State, 8-Fix Available".
>>
>> So I assume there must be another Bug Id for the same problem, but
>> neither could I find it in the bug database, nor is there a link from
>> Bug 6622432 to this other bug.
>>
>> So keeping track of all these bugs and codelines is already quite
>> difficult and shouldn't be even more complicated by the new model...
>>
>> Regards,
>> Volker
>>
>> On 2/21/09, Brad Wetmore <Bradford.Wetmore at sun.com> wrote:
>>>  Mark wrote:
>>>
>>>
>>>>> Also, add something like the following at the end of this section:
>>>>>
>>>>>     Some groups have already generated lists of "starter bugs" that
>>>>>     might contain useful ideas to get started.
>>>>>
>>>> Hmm; since this hasn't been done uniformly, and likely won't be soon,
>>>> I'm a bit reluctant to advertise it.
>>>>
>>>  You're probably right.  Now that I think about it, the list we 
>>> generated
>>> for the security group was about 2 years ago when Peabody was the 
>>> primary
>>> project contribution mechanism, and OpenJDK was just about ready to 
>>> go live.
>>>
>>>
>>>>> People are still signing up for accounts and registering to watch
>>>>> specific product categories and components, so there should be a 
>>>>> bit in
>>>>> here about "Announce your changes to the appropriate group's mailing
>>>>> list and request a sponsor" so that it doesn't get missed.  I'd 
>>>>> suggest
>>>>> putting it at the end of this section.
>>>>>
>>>> I'm not sure this is such a good idea.  The whole point of using 
>>>> Bugzilla
>>>> for contributions is to avoid relying upon people reading e-mail to see
>>>> that a contribution has come in.  I'd rather not encourage contributors
>>>> to send such e-mails, which in the worst case could be perceived by
>>>> potential sponsors as little more than spam.
>>>>
>>>  My original thought when I wrote this was that this would be a 
>>> temporary
>>> thing until the number of new accounts slows to a trickle and people are
>>> using it often.  But you're right, getting folks into that habit now 
>>> would
>>> be hard to break later.
>>>
>>>
>>>> We already intend to
>>>> review the incoming sponsorship requests on a regular basis and ping
>>>> likely sponsors; that should be sufficient.
>>>>
>>>  Contributors, please remember to set your "sponsor" flag!  ;)
>>>
>>>
>>>>>                        but for now we're just using Bugzilla for
>>>>> accepting contributions for bugs that already have bugids in
>>>>> Bugtraq/Bugster (Sun's internal bug tracking system).
>>>>>
>>>> Well, not exactly.  Contributors are also welcome to submit patches for
>>>> bugs or RFEs that do not already have corresponding Sun bug ids.
>>>>
>>>  Good to know, I hadn't grasped that subtlety.  Maybe that could be 
>>> called
>>> out a little more in Section 1?
>>>
>>>
>>>>> So how does this work with the SUNBUG (TRACKEDINBUGTRAQ) field of
>>> Bugzilla?
>>>>> If I understood this proposal right, say we have:
>>>>>
>>>>> 1)  Internal user has previously filed Bugtraq id 6000000.
>>>>> 2)  External user(s) wants to fix it, so they stake their claim in
>>>>> Bugzilla (Bugzilla id 100000), listing 6000000 in the summary or
>>>>> description field.
>>>>> 3)  Several users propose fixes.  Finally one is accepted as "The Fix"
>>>>> and is attached to the Bugzilla bug id.
>>>>> 4)  Sponsor accepts fix, integrates fix into JDK at 6000000, closes 
>>>>> the
>>>>> bugzilla bug as "SUNBUG", updates the Whiteboard with 
>>>>> "sunbug=6000000".
>>>>>
>>>>> Does that correspond to what you're thinking?
>>>>>
>>>> Not quite.  The SUNBUG resolution value is intended for the case of a
>>>> Bugzilla bug filed against a component whose bugs are only being 
>>>> tracked
>>>> in Sun's internal system.  The "sunbug=xxxxxxx" whiteboard entry is 
>>>> more
>>>> generally useful.  I think your scenario would work better as:
>>>>
>>>>  1) Internal user has previously filed Bugtraq id 6000000.
>>>>  2) External user(s) wants to fix it, so they stake their claim in
>>>>     Bugzilla (Bugzilla id 100000), adding "sunbug=6000000" to the
>>>>     bug's whiteboard.
>>>>  3) Several users propose fixes.  Finally one is accepted as "The Fix"
>>>>     and is attached to the Bugzilla bug.
>>>>  4) Sponsor evaluates fix, integrates it into the JDK at 6000000, and
>>>>     closes the bug as FIXDELIVERED/FIXED.
>>>>
>>>  Minor nit.  When the fix is put into one of the gates, the fix goes 
>>> to "fix
>>> available" in bugtraq.  It's the gatekeepers who mark as Fix Delivered.
>>> This means the sponsor must watch for the change to hit the MASTER 
>>> and then
>>> remember to move it to FIXDELIVERED, or else the gatekeepers must 
>>> realize
>>> that he has to update both.  Or just mark as FIXDELIVERED when it 
>>> goes into
>>> one of the GATES?  That'll be confusing.
>>>
>>>  Until we get Bugtraq/Bugzilla linked, this does require someone 
>>> duplicate
>>> the states in both the Bugzilla/Bugster bugids.  That's something to 
>>> address
>>> in the sponsor document.
>>>
>>>
>>>> On further thought I'm not going to add a "claim your bug" step just 
>>>> yet,
>>>> the possibility of which I mentioned last night in response to Neal's
>>>> comment.
>>>>
>>>  If people are following Section 2 ("discuss your intended change"), 
>>> this
>>> shouldn't be necessary.
>>>
>>>  Brad
>>>