Request for comments: New Bugzilla-based contribution process

[Volker Simonis]

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
>