Request for comments: New Bugzilla-based contribution process

[Mark Reinhold]

Now that we have Bugzilla up and running [1] (thanks, Brad!), it's time
to revise the existing e-mail-based patch-contribution process [2].

I've posted a first draft [3] on our shiny new code-review server
(thanks, Tim!).  Comments welcome.

- Mark


[1] http://mail.openjdk.java.net/pipermail/announce/2009-February/000069.html
[2] http://openjdk.java.net/contribute/
[3] http://cr.openjdk.java.net/~mr/new-contrib.html

[Neal Gafter]

Mark-

Is there any mechanism for contributors or committers to "claim" a bug -
that is, notify others that they're working on it - other than email?  Given
the contribution process you outlined, the main mechanism seems to be
creating a bugzilla bug, but is there any way to see that the bugzilla bug
has been created from the bugs.sun.com page?

-Neal

On Wed, Feb 18, 2009 at 8:49 PM, Mark Reinhold <mr@...> wrote:

> Now that we have Bugzilla up and running [1] (thanks, Brad!), it's time
> to revise the existing e-mail-based patch-contribution process [2].
>
> I've posted a first draft [3] on our shiny new code-review server
> (thanks, Tim!).  Comments welcome.
>
> - Mark
>
>
> [1]
> http://mail.openjdk.java.net/pipermail/announce/2009-February/000069.html
> [2] http://openjdk.java.net/contribute/
> [3] http://cr.openjdk.java.net/~mr/new-contrib.html<http://cr.openjdk.java.net/%7Emr/new-contrib.html>
>

[Mark Reinhold]

> Date: Wed, 18 Feb 2009 21:49:17 -0800
> From: Neal Gafter <neal@...>

> Is there any mechanism for contributors or committers to "claim" a bug -
> that is, notify others that they're working on it - other than email?  Given
> the contribution process you outlined, the main mechanism seems to be
> creating a bugzilla bug,

Right.

As stated this process doesn't really have a "claim" mechanism, since
presumably you'd like to claim a bug before doing a lot of work on it.
Perhaps the process should suggest that you create a Bugzilla entry first
in order to stake a claim, and then attach the patch and request a
sponsor once your work is complete.  If two or more developers want to
argue about the best way to fix a bug then they can do that in Bugzilla,
where a record will be kept for all to see.

>   but is there any way to see that the bugzilla bug
> has been created from the bugs.sun.com page?

That'd be ideal, but unfortunately it takes an absurdly long time to get
even the most trivial types of changes made to bugs.sun.com.  To see if
someone is working on a particular Sun bug I'm afraid the best approach
will be just to search all bugs.openjdk.java.net bugs for comments
containing the Sun bug's seven-digit id.

- Mark

[Brad Wetmore]

Comments on the new page first, then a response on the Mark/Neal exchange:

Mark Reinhold wrote:
> Now that we have Bugzilla up and running [1] (thanks, Brad!), it's time
> to revise the existing e-mail-based patch-contribution process [2].
>
> I've posted a first draft [3] on our shiny new code-review server
> (thanks, Tim!).  Comments welcome.

Section 1.

In the second para, there should be a link to the mail.o.j.n page and/or
the group pages so that people know where to go to find other people
working in the same areas.

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.

Section 3.

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.

Section 5.

     but rather to accept only high-quality contributions.

I would suggest adding an extra sentence here to remind folks that their
code could be used by millions of users, so it simply has to work.  It's
an awesome, but fulfilling responsibility.

 > Mark wrote:
 >> Neal wrote:
 >> Is there any mechanism for contributors or committers to "claim" a bug -
 >> that is, notify others that they're working on it - other than
email?  Given
 >> the contribution process you outlined, the main mechanism seems to be
 >> creating a bugzilla bug,
 >
 > As stated this process doesn't really have a "claim" mechanism, since
 > presumably you'd like to claim a bug before doing a lot of work on it.
 > Perhaps the process should suggest that you create a Bugzilla entry first
 > in order to stake a claim, and then attach the patch and request a
 > sponsor once your work is complete.  If two or more developers want to
 > argue about the best way to fix a bug then they can do that in Bugzilla,
 > where a record will be kept for all to see.

Just a reminder, the majority of bugs will eventually be handled
directly in Bugzilla, 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).

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?

Thanks,

Brad

[Mark Reinhold]

> Date: Thu, 19 Feb 2009 17:05:46 -0600
> From: bradford.wetmore@...

> Comments on the new page first, then a response on the Mark/Neal exchange:

Thanks for the detailed comments.

> Section 1.
>
> In the second para, there should be a link to the mail.o.j.n page and/or
> the group pages so that people know where to go to find other people
> working in the same areas.

Good idea.  Done.

> 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.

> Section 3.
>
> 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.  We already intend to
review the incoming sponsorship requests on a regular basis and ping
likely sponsors; that should be sufficient.

> Section 5.
>
>      but rather to accept only high-quality contributions.
>
> I would suggest adding an extra sentence here to remind folks that their
> code could be used by millions of users, so it simply has to work.  It's
> an awesome, but fulfilling responsibility.

Good point.  Done.

>> Mark wrote:
>>> Neal wrote:
>>> Is there any mechanism for contributors or committers to "claim" a bug -
>>> that is, notify others that they're working on it - other than
>>> email?  Given
>>> the contribution process you outlined, the main mechanism seems to be
>>> creating a bugzilla bug,
>>
>> As stated this process doesn't really have a "claim" mechanism, since
>> presumably you'd like to claim a bug before doing a lot of work on it.
>> Perhaps the process should suggest that you create a Bugzilla entry first
>> in order to stake a claim, and then attach the patch and request a
>> sponsor once your work is complete.  If two or more developers want to
>> argue about the best way to fix a bug then they can do that in Bugzilla,
>> where a record will be kept for all to see.
>
> Just a reminder, the majority of bugs will eventually be handled
> directly in Bugzilla,

Right.

> 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.

> 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.

This does point out the need for a corresponding "How to sponsor" page,
but let's try to get the "how to contribute" page done first.

I've posted a revised draft [1] incorporating the above changes.

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.  Let's see how things go and to what extent collisions actually
occur before we add complexity to the process.

- Mark


[1] http://cr.openjdk.java.net/~mr/new-contrib.html

[Volker Simonis]

Hi Mark,

I'm really happy that the Bugzilla is finally up and running. There is
however one point, which hasn't been addressed until now. It is
already hard to find all the information which belongs to a bug or
changeset. The easy way is from changeset to bug, but the other way
round, from Bug to changeset is already harder, because not every bug
links to the corresponding changeset. Not to mention the webrevs and
the discussions about the webrevs which happened on the mailing list
(see [1] for a previous discussion on this topic).

Now we get just two more system, the Bugzilla bug tracker and the
Community Code Review site [2]. While this is good thing in general,
how can we ensure that not only the bugzilla entry links to the Sun
bug via the "sunbug" entry, but also the Sun bug links back to the
corresponding Bugzilla entry. And how can we ensure to have a link
from the changelist and/or from the bug to the codereview? The
Bugzilla instance offers the great opportunity that discussions about
a webrev can take place in the open, inside Bugzilla and are preserved
there together with the bug. On the other hand, this hides the
discussions about webrevs from the lists. I don't know Bugzilla, but
perhaps it is possible to forward all changes of bugs from a certain
category(e.g. hotspot), to the corresponding mailing list?

What are your opinions about how we can get a consistent view of all
the information belonging to a bug?

Regards,
Volker

[1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2008-October/000756.html
[2] http://cr.openjdk.java.net/

On 2/19/09, Mark Reinhold <mr@...> wrote:

> Now that we have Bugzilla up and running [1] (thanks, Brad!), it's time
>  to revise the existing e-mail-based patch-contribution process [2].
>
>  I've posted a first draft [3] on our shiny new code-review server
>  (thanks, Tim!).  Comments welcome.
>
>  - Mark
>
>
>  [1] http://mail.openjdk.java.net/pipermail/announce/2009-February/000069.html
>  [2] http://openjdk.java.net/contribute/
>  [3] http://cr.openjdk.java.net/~mr/new-contrib.html
>

[Dalibor Topic-5]

Volker Simonis wrote:
> I don't know Bugzilla, but
> perhaps it is possible to forward all changes of bugs from a certain
> category(e.g. hotspot), to the corresponding mailing list?
>  
Almost - then people usually start complaining about being overwhelmed
by bug traffic about issues they
don't care about. ;) What I think we should have are bug watcher mailing
lists for each product in Bugzilla,
that people interested in a specific area can subscribe to and get their
fill of updates that way, rather then
dumping them on the regular list, in between the other review traffic,
discussions, etc.

cheers,
dalibor topic

--
*******************************************************************
Dalibor Topic                   Tel: [phone]
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: [phone]
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic@...
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring

[Volker Simonis]

On 2/20/09, Dalibor Topic <Dalibor.Topic@...> wrote:

> Volker Simonis wrote:
>
> > I don't know Bugzilla, but
> > perhaps it is possible to forward all changes of bugs from a certain
> > category(e.g. hotspot), to the corresponding mailing list?
> >
> >
>  Almost - then people usually start complaining about being overwhelmed by
> bug traffic about issues they
>  don't care about. ;) What I think we should have are bug watcher mailing
> lists for each product in Bugzilla,
>  that people interested in a specific area can subscribe to and get their
> fill of updates that way, rather then
>  dumping them on the regular list, in between the other review traffic,
> discussions, etc.
>

Yes, I completely agree except the part "in between the other review
traffic". My point was exactly that I want ALL the bits belonging to a
bug report in ONE central place and not split over mailing lists for
some sort of bugs, different bug tracking systems for another sort of
bugs and webrevs in different locations for yet another bugs (at least
in an ideal world this would be nice:).

Volker

[gnu_andrew]

2009/2/20 Dalibor Topic <Dalibor.Topic@...>:

> Volker Simonis wrote:
>>
>> I don't know Bugzilla, but
>> perhaps it is possible to forward all changes of bugs from a certain
>> category(e.g. hotspot), to the corresponding mailing list?
>>
>
> Almost - then people usually start complaining about being overwhelmed by
> bug traffic about issues they
> don't care about. ;) What I think we should have are bug watcher mailing
> lists for each product in Bugzilla,
> that people interested in a specific area can subscribe to and get their
> fill of updates that way, rather then
> dumping them on the regular list, in between the other review traffic,
> discussions, etc.
>

Can we make that a bug watcher mailing list (singular)?  We already
have a ridiculous number of lists, doubling that for watching bugs is
going to make things even crazier.

> cheers,
> dalibor topic
>
> --
> *******************************************************************
> Dalibor Topic                   Tel: [phone]
> Java F/OSS Ambassador           AIM: robiladonaim
> Sun Microsystems GmbH           Mobile: [phone]
> Nagelsweg 55                    http://openjdk.java.net
> D-20097 Hamburg                 mailto:Dalibor.Topic@...
> Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
> Amtsgericht München: HRB 161028
> Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
> Vorsitzender des Aufsichtsrates: Martin Häring
>
>
>
>

Cheers,
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[Dmitri Trembovetski]

Volker Simonis wrote:

> Hi Mark,
>
> I'm really happy that the Bugzilla is finally up and running. There is
> however one point, which hasn't been addressed until now. It is
> already hard to find all the information which belongs to a bug or
> changeset. The easy way is from changeset to bug, but the other way
> round, from Bug to changeset is already harder, because not every bug
> links to the corresponding changeset. Not to mention the webrevs and
> the discussions about the webrevs which happened on the mailing list
> (see [1] for a previous discussion on this topic).
>
> Now we get just two more system, the Bugzilla bug tracker and the
> Community Code Review site [2]. While this is good thing in general,
> how can we ensure that not only the bugzilla entry links to the Sun
> bug via the "sunbug" entry, but also the Sun bug links back to the
> corresponding Bugzilla entry. And how can we ensure to have a link
> from the changelist and/or from the bug to the codereview? The

   There could be a check-in hook which would update corresponding
   Bugzilla entry (and Sun internal bug id) with the changeset id and url.

   Thanks,
     Dmitri

> Bugzilla instance offers the great opportunity that discussions about
> a webrev can take place in the open, inside Bugzilla and are preserved
> there together with the bug. On the other hand, this hides the
> discussions about webrevs from the lists. I don't know Bugzilla, but
> perhaps it is possible to forward all changes of bugs from a certain
> category(e.g. hotspot), to the corresponding mailing list?
>
> What are your opinions about how we can get a consistent view of all
> the information belonging to a bug?
>
> Regards,
> Volker
>
> [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2008-October/000756.html
> [2] http://cr.openjdk.java.net/
>
> On 2/19/09, Mark Reinhold <mr@...> wrote:
>> Now that we have Bugzilla up and running [1] (thanks, Brad!), it's time
>>  to revise the existing e-mail-based patch-contribution process [2].
>>
>>  I've posted a first draft [3] on our shiny new code-review server
>>  (thanks, Tim!).  Comments welcome.
>>
>>  - Mark
>>
>>
>>  [1] http://mail.openjdk.java.net/pipermail/announce/2009-February/000069.html
>>  [2] http://openjdk.java.net/contribute/
>>  [3] http://cr.openjdk.java.net/~mr/new-contrib.html
>>

[Dalibor Topic-5]

Andrew John Hughes wrote:
> Can we make that a bug watcher mailing list (singular)?  We already
> have a ridiculous number of lists, doubling that for watching bugs is
> going to make things even crazier.
I think ideally we'd have both: a single list for people who enjoy the
buzz of regular, fresh e-mail
delivery without discriminating much about the subject, and watcher
lists for each product in the
bug tracker for people who are more interested in contributions in their
own area, then in others.

cheers,
dalibor topic

--
*******************************************************************
Dalibor Topic                   Tel: [phone]
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: [phone]
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic@...
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring

[jonathan.gibbons]

Why is it that after so many years of email, shared computing, Internet,
etc, this is
still such a difficult issue? Or if not difficult, then just unsolved.

-- Jon


Dalibor Topic wrote:

> Andrew John Hughes wrote:
>> Can we make that a bug watcher mailing list (singular)?  We already
>> have a ridiculous number of lists, doubling that for watching bugs is
>> going to make things even crazier.
> I think ideally we'd have both: a single list for people who enjoy the
> buzz of regular, fresh e-mail
> delivery without discriminating much about the subject, and watcher
> lists for each product in the
> bug tracker for people who are more interested in contributions in
> their own area, then in others.
>
> cheers,
> dalibor topic
>

[Brad Wetmore]

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

[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@.../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@...> 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
>

[Brad Wetmore]

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@.../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@...> 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
>>

[Roger Lewis]

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@.../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@...> 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
>>>

[Joseph D. Darcy]

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@.../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".
>  

The HotSpot code is maintained a bit differently than the rest of the 6
update release train; the rest of the that release train is maintained
in the legacy teamware SCM system.

-Joe

[Mark Reinhold]

> Date: Sat, 21 Feb 2009 14:25:11 -0600
> From: bradford.wetmore@...

> Mark wrote:
>> Brad wrote:
>>> 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?

Done.

>> ...
>>
>> 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.

I agree.  The simplest thing is probably for a sponsor to set the
Bugzilla bug's state to FIXAVAILABLE and then later change it to
FIXDELIVERED when corresponding Sun bug is updated to that state.

> 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.

Agreed.

- Mark

[Mark Reinhold]

> Date: Fri, 20 Feb 2009 12:33:29 +0100
> From: volker.simonis@...

> I'm really happy that the Bugzilla is finally up and running. There is
> however one point, which hasn't been addressed until now. It is
> already hard to find all the information which belongs to a bug or
> changeset. The easy way is from changeset to bug, but the other way
> round, from Bug to changeset is already harder, because not every bug
> links to the corresponding changeset. Not to mention the webrevs and
> the discussions about the webrevs which happened on the mailing list
> (see [1] for a previous discussion on this topic).
>
> Now we get just two more system, the Bugzilla bug tracker and the
> Community Code Review site [2]. While this is good thing in general,
> how can we ensure that not only the bugzilla entry links to the Sun
> bug via the "sunbug" entry, but also the Sun bug links back to the
> corresponding Bugzilla entry. And how can we ensure to have a link
> from the changelist and/or from the bug to the codereview? The
> Bugzilla instance offers the great opportunity that discussions about
> a webrev can take place in the open, inside Bugzilla and are preserved
> there together with the bug. On the other hand, this hides the
> discussions about webrevs from the lists. I don't know Bugzilla, but
> perhaps it is possible to forward all changes of bugs from a certain
> category(e.g. hotspot), to the corresponding mailing list?
>
> What are your opinions about how we can get a consistent view of all
> the information belonging to a bug?

You raise some very good points here.  Until the Semantic Web becomes a
reality, however, and we all start writing all our documents in perfectly
cross-linked XML, I'm afraid the best we can do is identify reasonable
tools and practices to help us live with our ever-growing tangled web of
documents.

As Dmitri suggested later on, automating the cross-linkage of bug reports
and changesets should be straightforward and is something we should look
into.

Linking Sun bugs back to Bugzilla bugs can also be automated, by scanning
Bugzilla bugs for sunbug= properties and planting corresponding reverse
links in the Sun bug database.

Linking code reviews on cr.openjdk.java.net to, and from, the bug
databases should be possible with a bit of work.  If people consistently
name their top-level review directories with bug numbers then it's easy;
if not then we'll have to come up with some other way to convey that
information.

The harder problem is e-mail.  We can encourage people to use Bugzilla
comments, but the e-mail habit runs strong and deep -- especially within
Sun -- so that's likely to prove an uphill battle.  Fortunately Google
is pretty good at looking for contiguous strings of digits; I'm afraid
that's the best solution that I know of in the near term.

In the longer term it'd be nice to have a tool like Review Board set up
for code reviews, but that's not something we'll have time for in the
next few months.

FYI I've created a few (Bugzilla!) bugs to capture the linkage ideas
that could be implemented near-term [1].

- Mark


[1] https://bugs.openjdk.java.net/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=web&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&bug_status=NEW&bug_status=ACCEPTED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

[Mark Reinhold]

> Date: Fri, 20 Feb 2009 16:21:30 +0000
> From: Andrew John Hughes <gnu_andrew@...>

> ...
>
> Can we make that a bug watcher mailing list (singular)?  We already
> have a ridiculous number of lists, doubling that for watching bugs is
> going to make things even crazier.

Brad is in the process of setting up a single "watch-all" watcher
account in Bugzilla, so if you really want to see every update then
you can follow that.  There will also be per-product watch lists,
e.g., "watch-hotspot" for all HotSpot bugs, but at the moment those
are less interesting since at the moment most (all?) products only
have an "other" component.

- Mark