Commit responsibilities and Lines of Defense

Bradford Wetmore bradford.wetmore at
Tue Feb 22 08:00:34 UTC 2011

 >> Kelly just wrote:
 >> >    >  It's not clear...and slightly augmented by the openjdk bugzilla.
 >> >
 >> >  I think Andrew was referring to
 > I was.  I'm not sure what else the phrase "OpenJDK bug database"
 > would refer to.

There were several bug systems mentioned in Kelly's post, and are used 
in varying ways for JDK:

     Sun's internal bug database
     Bug parade ( which seeds from that system
     Oracle's internal bug database

I just wanted to make sure we were talking about the same system.

>> That's
>> where we are now.  bugs.o.j.n is still the place to submit/track
>> patches, and I expect data from that bugzilla instance will be migrated
>> to the new system.
> I never got the impression that the Bugzilla instance was only intended for
> stage 1 and doesn't read
> like that either:
> 'Goal
> To produce a Bugzilla instance in which OpenJDK contributions, bugs
> and RFEs can be submitted, tracked, and modified by people both
> internal and external to Sun.'
> Is that goal no longer valid?

What you stated was the full goal, but as enumerated in the Phases 
section, the deployment steps were first to track patches, then expand 
to the general bug tracking solution for OpenJDK, then connect to Sun's 
internal database.  It didn't get further than stage 1 before those 
major factors came into play, and things got put on hold until our new 
Oracle environment was understood.

 >>   This
 >> bugzilla instance was set up to track patch contributions until a more
 >> permanent bug tracking solution could be developed/deployed.

I composed that sentence poorly.  The "more permanent solution" was to 
extend/expand the bugzilla instance to do OpenJDK bug tracking.

It was not "only intended for stage 1."  I was not clear about that, and 
my apologies.

>>   >  (and we did a poor job of watching over the bugzilla system, sorry).
>> The expectation was that patch submissions should be made visible by the
>> submitter and discussed on the project team's mailing list.
> I don't remember this ever being made clear.

We tried to describe it in the contributions page:

     2. Discuss your intended change
     3. Submit a patch

     When your change is ready, create a new bug report in the OpenJDK
     Bugzilla system.
     Use attachments to your bug report to convey the following:

>  All the Bugzilla page
> says is:
> 'The primary goal of this phase is to further open our development
> processes, and prevent submissions from getting lost in the mailing
> list archives'

We probably could have reiterated the above here on this page also.

> I don't see how having discussion in two different places helps.  I
> guess that's why the database wasn't a success.
>> bugs.o.j.n was not supposed to track bugs, although some people
>> submitted bugs without patches, and which obviously didn't gain much
>> visibility.

I should have said "not supposed to track bugs *yet*".  I can see how 
that was interpreted.

Each page of the bugzilla instance does contain the following header:

     During the initial rollout phase, this site will only be accepting
     and tracking patch contributions to the OpenJDK 6 and 7 forests.
     Until the remainder of the site is ready, please continue to file
     normal bug reports via

     Regular bug reports filed here during the rollout period will be
     summarily closed.

> In phase 1, yes.  I don't think it was ever intended that this would be
> its only remit.  Again, the Bugzilla group page says:
> 'During later phases of this project, we will be linking the Bugzilla
> instance with Bugtraq'

> I think we can all agree that the Bugzilla setup suffered from the
> Oracle merger happening and didn't evolve as was originally planned.

I am in complete agreement.  Now that the efforts for bug tracking have 
been restarted, I'm encouraging that the effort be staffed with folks 
who can focus solely on this project.

> Let's not try and revise history by pretending it was only ever
> intended to be a patch repository.

A misunderstanding, my apologies for not making that clearer.

 > So I take it the previous democratic choice of Bugzilla may be
 > ignored?

For now, patch submissions should continue to be submitted via bugzilla, 
and discussed with the appropriate project team.


More information about the build-dev mailing list