Request for comments: New Bugzilla-based contribution process

Mon Feb 23 17:08:57 UTC 2009

Brad,

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.

Field relationship:
   Release Fixed points to BT's Integrated
   State points to BT State, filtering is no longer being done.

-Roger

Brad Wetmore wrote:
>
> 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
>>>