Request for comments: New Bugzilla-based contribution process
Bradford.Wetmore at Sun.COM
Sat Feb 21 20:25:11 UTC 2009
>> 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
If people are following Section 2 ("discuss your intended change"), this
shouldn't be necessary.
More information about the discuss