Nabble - OpenJDK Site Infrastructure

Re: Mercurial server down?

2009-11-11T20:28:16Z

> Date: Wed, 11 Nov 2009 17:02:56 -0800
> From: kelly.ohair@...

> Cannot access http://hg.openjdk.java.net/jdk7/jdk7

Fixed.

- Mark

Re: Mercurial server down?

2009-11-11T17:17:58Z

2009/11/12 Tim Bell <Tim.Bell@...>:
> Kelly-
>> Cannot access http://hg.openjdk.java.net/jdk7/jdk7
>
> Checking...
>
> Tim
>

Can't access it here either.
--
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

Re: Mercurial server down?

2009-11-11T17:12:01Z

Kelly-
> Cannot access http://hg.openjdk.java.net/jdk7/jdk7

Checking...

Tim

Mercurial server down?

2009-11-11T17:02:56Z

FYI...

Cannot access http://hg.openjdk.java.net/jdk7/jdk7

-kto

Re: Patch for JTreg test java/net/MulticastSocket/SetOutgoingIf.java

2009-09-23T10:48:58Z

Andrew John Hughes wrote:

> 2009/9/23 Andrew Haley <aph@...>:
>> Andrew John Hughes wrote:
>>> 2009/9/23 Andrew Haley <aph@...>:
>>>> Christopher Hegarty -Sun Microsystems Ireland wrote:
>>>>> [cc'ing net-dev]
>>>>>
>>>>> I see you have push access, so if you make the appropriate changes
>>>>> (mentioned above) I can review the webrev and you can use the above bug
>>>>> number and description to push the changeset.
>>>> Please make sure you tell Pavel which forest to push to. It's sometimes
>>>> hard for us outside Sun to know.
>>> http://openjdk.java.net/guide/repositories.html
>> Yeah, I know. It's still a good idea for the approver to tell newbie
>> contributors which forest to push to.
>>
>> Andrew.
>>
>
> Oh, I agree. I just thought I'd use the opportunity to point out to
> everyone that a) there is some documentation of this and, more
> importantly, b) it needs updating.

I will try and see if I can do some updating to this repositories page.

If there are other problems with this page, let me know I'll try and
include the changes people tell me about, within reason of course.. ;^)

-kto

Re: hg push getting worse?

2009-09-11T15:36:04Z

I've written a script to reap old changegroup snapshots, and removed
all snapshots older than 14 days (excepting the latest snapshot of
each repo filesystem). A push to hg.ojn now takes about 20 seconds.

I'll set up a cron job to reap snapshots on a regular basis.

Further improvement will be possible after we migrate to the new
datacenter, but for now 20 seconds << 5 minutes.

- Mark

Re: hg push getting worse?

2009-09-08T14:23:04Z

Pushes to hg.ojn now take over 10 minutes. What does it take to fix this before
it's faster to do a Teamware bringover of the j2se repository than to push a couple
of files to hg.ojn?

-- Jon

real   10m7.790s
user   0m0.192s
sys   0m0.048s

Jonathan Gibbons wrote:

Any chance of that upgrade happening? What would it take to make it happen?

-- Jon

Tim Bell wrote:

I wrote:

ZFS snapshots are supposed to be lightweight and inexpensive.  We
still have them going back to the beginning of time on hg.ojn.

Perhaps we have accumulated enough to expose quadratic (or worse)
performance problems.  I will do some searching over on OpenSolaris.


I spent ten or fifteen minutes searching on this issue.  The short
version is that there has been a significant amount of ZFS
performance work done since
  "Solaris Express Developer Edition 9/07 snv_70a X86"
which is the release hg.ojn is running.  That was the best choice
back when we set the server up, but now it is pretty old.

Here are a few examples - all of these are marked FIXed in builds
more recent than 70a.  (FYI: OpenSolaris is currently up around b121):

6596190 ""zfs list" is slow due to version property"
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6596190

6386929 "initial "zfs list" is slow"
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6386929

6755389 "Initial run of any zfs command that iterates over datasets can be slow"
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6755389

Here is a message thread related to 'zfs list' being slow:
  http://mail.opensolaris.org/pipermail/zfs-discuss/2008-July/019956.html


hg.ojn has been extremely stable since we set it up - it currently
has 652 days of uptime.  All the same, it it probably time to start
planning an upgrade.

Tim

Re: hg push getting worse?

2009-08-27T11:16:09Z

Any chance of that upgrade happening? What would it take to make it happen?

-- Jon

Tim Bell wrote:

I wrote:

ZFS snapshots are supposed to be lightweight and inexpensive.  We
still have them going back to the beginning of time on hg.ojn.

Perhaps we have accumulated enough to expose quadratic (or worse)
performance problems.  I will do some searching over on OpenSolaris.


I spent ten or fifteen minutes searching on this issue.  The short
version is that there has been a significant amount of ZFS
performance work done since
  "Solaris Express Developer Edition 9/07 snv_70a X86"
which is the release hg.ojn is running.  That was the best choice
back when we set the server up, but now it is pretty old.

Here are a few examples - all of these are marked FIXed in builds
more recent than 70a.  (FYI: OpenSolaris is currently up around b121):

6596190 ""zfs list" is slow due to version property"
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6596190

6386929 "initial "zfs list" is slow"
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6386929

6755389 "Initial run of any zfs command that iterates over datasets can be slow"
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6755389

Here is a message thread related to 'zfs list' being slow:
  http://mail.opensolaris.org/pipermail/zfs-discuss/2008-July/019956.html


hg.ojn has been extremely stable since we set it up - it currently
has 652 days of uptime.  All the same, it it probably time to start
planning an upgrade.

Tim

Re: hg push getting worse?

2009-08-13T13:33:23Z

I wrote:

> ZFS snapshots are supposed to be lightweight and inexpensive. We
> still have them going back to the beginning of time on hg.ojn.
>
> Perhaps we have accumulated enough to expose quadratic (or worse)
> performance problems. I will do some searching over on OpenSolaris.

I spent ten or fifteen minutes searching on this issue. The short
version is that there has been a significant amount of ZFS
performance work done since
"Solaris Express Developer Edition 9/07 snv_70a X86"
which is the release hg.ojn is running. That was the best choice
back when we set the server up, but now it is pretty old.

Here are a few examples - all of these are marked FIXed in builds
more recent than 70a. (FYI: OpenSolaris is currently up around b121):

6596190 ""zfs list" is slow due to version property"
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6596190

6386929 "initial "zfs list" is slow"
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6386929

6755389 "Initial run of any zfs command that iterates over datasets can be slow"
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6755389

Here is a message thread related to 'zfs list' being slow:
http://mail.opensolaris.org/pipermail/zfs-discuss/2008-July/019956.html

hg.ojn has been extremely stable since we set it up - it currently
has 652 days of uptime. All the same, it it probably time to start
planning an upgrade.

Tim

Re: hg push getting worse?

2009-08-11T15:04:07Z

> I don't know the openjdk infrastructure, so am just guessing, but I
> suspect there are only a finite number of snapshots maintained. The
> benefit is being able to recover :-). AFAIK, we've only used it once
> or twice, but having the snapshots made it possible.

I was just on the hg server to shake loose a changeset in the
jdk6-gate/langtools repo.

The most obvious thing is that the push script is spending a lot of
time running '/sbin/zfs list -Ho mountpoint,name'

Running only that command by hand takes 3 mins 17 secs and produces
11485 lines of output.

During that time, truss reports hundreds of these:

brk(0x0CC6F000) = 0
ioctl(3, ZFS_IOC_SNAPSHOT_LIST_NEXT, 0x08042E08) = 0
ioctl(3, ZFS_IOC_OBJSET_STATS, 0x08040F68) = 0
ioctl(3, ZFS_IOC_SNAPSHOT_LIST_NEXT, 0x08042E08) = 0
ioctl(3, ZFS_IOC_OBJSET_STATS, 0x08040F68) = 0
ioctl(3, ZFS_IOC_SNAPSHOT_LIST_NEXT, 0x08042E08) = 0
ioctl(3, ZFS_IOC_OBJSET_STATS, 0x08040F68) = 0
ioctl(3, ZFS_IOC_SNAPSHOT_LIST_NEXT, 0x08042E08) = 0
ioctl(3, ZFS_IOC_OBJSET_STATS, 0x08040F68) = 0
ioctl(3, ZFS_IOC_SNAPSHOT_LIST_NEXT, 0x08042E08) = 0
ioctl(3, ZFS_IOC_OBJSET_STATS, 0x08040F68) = 0

ZFS snapshots are supposed to be lightweight and inexpensive. We
still have them going back to the beginning of time on hg.ojn.

Perhaps we have accumulated enough to expose quadratic (or worse)
performance problems. I will do some searching over on OpenSolaris.

Tim

Re: hg push getting worse?

2009-08-11T14:28:55Z

John Coomes wrote:

Jonathan Gibbons (Jonathan.Gibbons@...) wrote:

John Coomes wrote:

Andrew John Hughes (gnu_andrew@...) wrote:

2009/8/11 John Coomes John.Coomes@...:

Is there any further news on whether the forest extension will become
a standard part of Mercurial? When I went searching for a client-side
version to support newer versions, I had to resort to using a snapshot
of their repository for forest.

I doubt forest will ever become part of mercurial.  Mercurial now has
an experimental sub-repo feature for dealing with nested repositories.
It doesn't have the flexibility of the forest extension, so wouldn't
work for openjdk, at least as it stands now.

What are the issues with the Mercurial sub-repos. It seems close to what 
we want.
What is the lack of flexibility that you have observed that concerns you?


The main one is the inability to get a partial tree.  But there's also
the inability to avoid recursing into sub-repos when doing an update.
There were a couple of requests for the latter on the mercurial-devel
list, but I don't think anything has happened.  And it seems to be
just an implementation problem, but the location of the sub-repos is
kept in a versioned file which can't be overridden from the command
line.

-John

Ouch. Thanks for the update.

-- Jon

Re: hg push getting worse?

2009-08-11T14:10:51Z

Jonathan Gibbons (Jonathan.Gibbons@...) wrote:

> John Coomes wrote:
> > Andrew John Hughes (gnu_andrew@...) wrote:
> >
> >> 2009/8/11 John Coomes <John.Coomes@...>:
> >>
> >> Is there any further news on whether the forest extension will become
> >> a standard part of Mercurial? When I went searching for a client-side
> >> version to support newer versions, I had to resort to using a snapshot
> >> of their repository for forest.
> >
> > I doubt forest will ever become part of mercurial. Mercurial now has
> > an experimental sub-repo feature for dealing with nested repositories.
> > It doesn't have the flexibility of the forest extension, so wouldn't
> > work for openjdk, at least as it stands now.
>
>
> What are the issues with the Mercurial sub-repos. It seems close to what
> we want.
> What is the lack of flexibility that you have observed that concerns you?

The main one is the inability to get a partial tree. But there's also
the inability to avoid recursing into sub-repos when doing an update.
There were a couple of requests for the latter on the mercurial-devel
list, but I don't think anything has happened. And it seems to be
just an implementation problem, but the location of the sub-repos is
kept in a versioned file which can't be overridden from the command
line.

-John

Re: hg push getting worse?

2009-08-11T13:34:06Z

2009/8/11 John Coomes <John.Coomes@...>:

> Andrew John Hughes (gnu_andrew@...) wrote:
>> 2009/8/11 John Coomes <John.Coomes@...>:
>> > I think jcheck is relatively light-weight compared to the zfs snapshot
>> > and auto-push that are also done. Â But it would be nice to know for
>> > sure.
>>
>> True. It's hard to tell from the client side as hg appears to hang
>> 'searching for changes' and then suddenly a burst of information
>> appears, either reporting success or failure. I presume this is part
>> of the design of hg unfortunately, but it would be helpful if things
>> were more verbose. I presume hooks were never meant to utilise enough
>> time that this would become an issue.
>>
>> I can see how zfs snapshotting would take longer over time. Although
>> the snapshots are, I presume, relative to the last so that the size
>> remains fairly sane, the sheer number of them is likely to cause a
>> slowdown. Is there a significant benefit to creating these?
>
> I don't know the openjdk infrastructure, so am just guessing,

Same here.

but I
> suspect there are only a finite number of snapshots maintained. The
> benefit is being able to recover :-). AFAIK, we've only used it once
> or twice, but having the snapshots made it possible.
>

Ah, sounds worth it then ;)

>> ... And are
>> they also created in Maurizio's FX project?
>
> I have no idea.
>
>> >> > jcheck appears to perform its check on the changeset once committed to
>> >> > the remote repository and then performs a rollback if it fails,
>> >> > although you don't see any of this feedback in realtime on the client.
>> >> > Ã‚Â I presume this also means it has to get Mercurial to generate the
>> >> > changeset (and others for the bugid check) which would take time.
>> >
>> > That's the standard way that mercurial hooks work, and the reason we
>> > have the extra *-gate forests. Â In more recent versions of mercurial,
>> > the pending changesets aren't visible until the hooks have completed
>> > successfully, so the *-gate forests become unnecessary. Â We haven't
>> > been able to update because the server-side of the forest extension
>> > doesn't work w/recent mercurial releases.
>> >
>>
>> Is there any further news on whether the forest extension will become
>> a standard part of Mercurial? When I went searching for a client-side
>> version to support newer versions, I had to resort to using a snapshot
>> of their repository for forest.
>
> I doubt forest will ever become part of mercurial. Mercurial now has
> an experimental sub-repo feature for dealing with nested repositories.
> It doesn't have the flexibility of the forest extension, so wouldn't
> work for openjdk, at least as it stands now.
>
>> ...
>> All changes have to be approved first, so could not this issue be
>> flagged at that point? The history could also be scanned for
>> duplicates at that point if someone really wanted to be sure. The
>> case is even worse with the whitespace checks. Given jcheck clearly
>> can find the issues, can it not also fix them? Or could some of these
>> checks be applied on the client-side? Worst case, could the whole
>> repo. not just be sanitised on a regular basis? As is, you push a
>> commit, wait several minutes and then get a result from jcheck saying
>> there is an extra space at the end of one line. So, you have to
>> rollback the commit, remove the space, reapply the commit with the
>> same comments and then push again. In all, a lot of time is spent for
>> very little gain.
>
> I think the problem is access to jcheck. I'm not sure why it isn't
> available externally. We run jcheck on our local repos before
> pushing, and it's reasonably convenient. Or maybe I should say not
> too inconvenient :-).
>

Exactly. Now I know about them (through failed changesets), I could
probably come up with my own checks for the whitespace issues I
mentioned, but I have no idea what other checks may be being performed
by jcheck. It's a black box, and our only evidence of its behaviour
is by testing with our changesets as input.

> -John
>
>

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

Re: hg push getting worse?

2009-08-11T13:27:57Z

John Coomes wrote:

Andrew John Hughes (gnu_andrew@...) wrote:

2009/8/11 John Coomes John.Coomes@...:

Is there any further news on whether the forest extension will become
a standard part of Mercurial? When I went searching for a client-side
version to support newer versions, I had to resort to using a snapshot
of their repository for forest.


I doubt forest will ever become part of mercurial.  Mercurial now has
an experimental sub-repo feature for dealing with nested repositories.
It doesn't have the flexibility of the forest extension, so wouldn't
work for openjdk, at least as it stands now.

What are the issues with the Mercurial sub-repos. It seems close to what we want.
What is the lack of flexibility that you have observed that concerns you?

-- Jon

Re: hg push getting worse?

2009-08-11T12:34:01Z

Andrew John Hughes (gnu_andrew@...) wrote:

> 2009/8/11 John Coomes <John.Coomes@...>:
> > I think jcheck is relatively light-weight compared to the zfs snapshot
> > and auto-push that are also done. Â But it would be nice to know for
> > sure.
>
> True. It's hard to tell from the client side as hg appears to hang
> 'searching for changes' and then suddenly a burst of information
> appears, either reporting success or failure. I presume this is part
> of the design of hg unfortunately, but it would be helpful if things
> were more verbose. I presume hooks were never meant to utilise enough
> time that this would become an issue.
>
> I can see how zfs snapshotting would take longer over time. Although
> the snapshots are, I presume, relative to the last so that the size
> remains fairly sane, the sheer number of them is likely to cause a
> slowdown. Is there a significant benefit to creating these?

I don't know the openjdk infrastructure, so am just guessing, but I
suspect there are only a finite number of snapshots maintained. The
benefit is being able to recover :-). AFAIK, we've only used it once
or twice, but having the snapshots made it possible.

> ... And are
> they also created in Maurizio's FX project?

I have no idea.

> >> > jcheck appears to perform its check on the changeset once committed to
> >> > the remote repository and then performs a rollback if it fails,
> >> > although you don't see any of this feedback in realtime on the client.
> >> > ÃÂ I presume this also means it has to get Mercurial to generate the
> >> > changeset (and others for the bugid check) which would take time.
> >
> > That's the standard way that mercurial hooks work, and the reason we
> > have the extra *-gate forests. Â In more recent versions of mercurial,
> > the pending changesets aren't visible until the hooks have completed
> > successfully, so the *-gate forests become unnecessary. Â We haven't
> > been able to update because the server-side of the forest extension
> > doesn't work w/recent mercurial releases.
> >
>
> Is there any further news on whether the forest extension will become
> a standard part of Mercurial? When I went searching for a client-side
> version to support newer versions, I had to resort to using a snapshot
> of their repository for forest.

I doubt forest will ever become part of mercurial. Mercurial now has
an experimental sub-repo feature for dealing with nested repositories.
It doesn't have the flexibility of the forest extension, so wouldn't
work for openjdk, at least as it stands now.

> ...
> All changes have to be approved first, so could not this issue be
> flagged at that point? The history could also be scanned for
> duplicates at that point if someone really wanted to be sure. The
> case is even worse with the whitespace checks. Given jcheck clearly
> can find the issues, can it not also fix them? Or could some of these
> checks be applied on the client-side? Worst case, could the whole
> repo. not just be sanitised on a regular basis? As is, you push a
> commit, wait several minutes and then get a result from jcheck saying
> there is an extra space at the end of one line. So, you have to
> rollback the commit, remove the space, reapply the commit with the
> same comments and then push again. In all, a lot of time is spent for
> very little gain.

I think the problem is access to jcheck. I'm not sure why it isn't
available externally. We run jcheck on our local repos before
pushing, and it's reasonably convenient. Or maybe I should say not
too inconvenient :-).

-John

Re: hg push getting worse?

2009-08-11T11:58:20Z

2009/8/11 John Coomes <John.Coomes@...>:

> Andrew John Hughes (gnu_andrew@...) wrote:
>> > ...
>> > From my experience with the OpenJDK servers, I think it may be jcheck.
>> > Â Unfortunately, jcheck itself is not Free Software, so it is
>> > impossible for me to say for definite. Â Instead, we seem to be
>> > discovering what checks it performs only when failures occur.
>> >
>> > I do know it does the following:
>> >
>> > * Checks the use of whitespace in changesets, rejecting the use of
>> > tabs and trailing whitespace.
>> > * Checks the format of the commit message. Â It must even follow the
>> > bugid/summary/reviewer format documented in the developer guide or
>> > simply be 'Merge'.
>> > * Checks that the bugid used is not used by any other changeset.
>> >
>> > I've run into all of these with different changesets. Â I can
>> > definitely see how the latter could take a while on something like the
>> > jdk repository (which dwarfs the others in size).
>
> I think jcheck is relatively light-weight compared to the zfs snapshot
> and auto-push that are also done. But it would be nice to know for
> sure.
>

True. It's hard to tell from the client side as hg appears to hang
'searching for changes' and then suddenly a burst of information
appears, either reporting success or failure. I presume this is part
of the design of hg unfortunately, but it would be helpful if things
were more verbose. I presume hooks were never meant to utilise enough
time that this would become an issue.

I can see how zfs snapshotting would take longer over time. Although
the snapshots are, I presume, relative to the last so that the size
remains fairly sane, the sheer number of them is likely to cause a
slowdown. Is there a significant benefit to creating these? And are
they also created in Maurizio's FX project?

>> > jcheck appears to perform its check on the changeset once committed to
>> > the remote repository and then performs a rollback if it fails,
>> > although you don't see any of this feedback in realtime on the client.
>> > Â I presume this also means it has to get Mercurial to generate the
>> > changeset (and others for the bugid check) which would take time.
>
> That's the standard way that mercurial hooks work, and the reason we
> have the extra *-gate forests. In more recent versions of mercurial,
> the pending changesets aren't visible until the hooks have completed
> successfully, so the *-gate forests become unnecessary. We haven't
> been able to update because the server-side of the forest extension
> doesn't work w/recent mercurial releases.
>

Is there any further news on whether the forest extension will become
a standard part of Mercurial? When I went searching for a client-side
version to support newer versions, I had to resort to using a snapshot
of their repository for forest.

>> > It would be much better if we could perform these sanity checks
>> > locally, though we'd still need some way of checking this had been
>> > done on the server side (or who knows, we could trust the developers
>> > to have done it...).
>>
>> I should also note that duplicate bugids can appear completely
>> legitimately in certain merge cases. This is the current issue with
>> updating OpenJDK6's HotSpot.. Fixes for bugs occur both in the
>> original (rebased) OpenJDK6 HotSpot and the copy of HotSpot being
>> merged from the hs14 repository, resulting in duplicate bugids which
>> jcheck rejects. I presume this is to protect against the case that
>> someone mistypes the bugid as another legitimate bugid, but it is
>> certainly an expensive check for what seems a fairly unlikely
>> occurrence.
>
> The goal is to prevent people from checking in fixes piece-meal,
> scattering a bug fix over 2, 3 or more changesets. Having a bug fix
> isolated to a single changeset makes backporting it to a different
> release much, much easier. We lived with the practice of partial
> fixes for quite some time, and I'd rather not go back.
>

I agree. I'm just not sure that the best way of enforcing this is a
technical one. The OpenJDK6 example is fairly convoluted, but I
imagine our IcedTea forest would be prone to this too, were it to be
jchecked. We often commit a fix there early, and then also receive
the same fix in a later pull from the JDK7 forest.

All changes have to be approved first, so could not this issue be
flagged at that point? The history could also be scanned for
duplicates at that point if someone really wanted to be sure. The
case is even worse with the whitespace checks. Given jcheck clearly
can find the issues, can it not also fix them? Or could some of these
checks be applied on the client-side? Worst case, could the whole
repo. not just be sanitised on a regular basis? As is, you push a
commit, wait several minutes and then get a result from jcheck saying
there is an extra space at the end of one line. So, you have to
rollback the commit, remove the space, reapply the commit with the
same comments and then push again. In all, a lot of time is spent for
very little gain.

> -John
>
>

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

Re: hg push getting worse?

2009-08-11T11:33:33Z

Andrew John Hughes (gnu_andrew@...) wrote:

> > ...
> > From my experience with the OpenJDK servers, I think it may be jcheck.
> > Â Unfortunately, jcheck itself is not Free Software, so it is
> > impossible for me to say for definite. Â Instead, we seem to be
> > discovering what checks it performs only when failures occur.
> >
> > I do know it does the following:
> >
> > * Checks the use of whitespace in changesets, rejecting the use of
> > tabs and trailing whitespace.
> > * Checks the format of the commit message. Â It must even follow the
> > bugid/summary/reviewer format documented in the developer guide or
> > simply be 'Merge'.
> > * Checks that the bugid used is not used by any other changeset.
> >
> > I've run into all of these with different changesets. Â I can
> > definitely see how the latter could take a while on something like the
> > jdk repository (which dwarfs the others in size).

I think jcheck is relatively light-weight compared to the zfs snapshot
and auto-push that are also done. But it would be nice to know for
sure.

> > jcheck appears to perform its check on the changeset once committed to
> > the remote repository and then performs a rollback if it fails,
> > although you don't see any of this feedback in realtime on the client.
> > Â I presume this also means it has to get Mercurial to generate the
> > changeset (and others for the bugid check) which would take time.

That's the standard way that mercurial hooks work, and the reason we
have the extra *-gate forests. In more recent versions of mercurial,
the pending changesets aren't visible until the hooks have completed
successfully, so the *-gate forests become unnecessary. We haven't
been able to update because the server-side of the forest extension
doesn't work w/recent mercurial releases.

> > It would be much better if we could perform these sanity checks
> > locally, though we'd still need some way of checking this had been
> > done on the server side (or who knows, we could trust the developers
> > to have done it...).
>
> I should also note that duplicate bugids can appear completely
> legitimately in certain merge cases. This is the current issue with
> updating OpenJDK6's HotSpot.. Fixes for bugs occur both in the
> original (rebased) OpenJDK6 HotSpot and the copy of HotSpot being
> merged from the hs14 repository, resulting in duplicate bugids which
> jcheck rejects. I presume this is to protect against the case that
> someone mistypes the bugid as another legitimate bugid, but it is
> certainly an expensive check for what seems a fairly unlikely
> occurrence.

The goal is to prevent people from checking in fixes piece-meal,
scattering a bug fix over 2, 3 or more changesets. Having a bug fix
isolated to a single changeset makes backporting it to a different
release much, much easier. We lived with the practice of partial
fixes for quite some time, and I'd rather not go back.

-John

A little gift - Sam

2009-05-30T04:24:07Z

Sam Pal belongs to Skoost and sent you a little gift.

Click below to collect your gift:
http://uk.skoost.com/fun?web%2Ddiscuss%40openjdk%2Ejava%2Enet/17345347/3

P.S. This is a safe and innocent gift that Sam Pal
sent from Skoost, the free goodies website.

This e-mail was sent to web-discuss@... on 5/28/2009 8:05:53 AM
on behalf of Sam Pal (samadhanpalkar@...)

Re: who should use bugzilla ?

2009-05-01T11:22:07Z

> it was even
> officially named "bug parade" in former times.

I was just checking to make sure it wasn't getting confused with
Bugzilla. I am working on the Bugzilla piece, but have no control over
bugs.sun.com.

>>> Especially on the bug parade I'm missing:
>>> - sophisticated search tools
>>> - saving search profiles
>>> - reopening bugs from external
>>> - attaching resources
>>> - customising the watch list, e.g. displaying the summary in the list
>>> (today only id's are displayed, and you have to open all links, to
>>> see what's inside)

I agree with you!

Brad

Ulf Zibis wrote:

> I'm talking about bugs.sun.com, as I remember right, it was even
> officially named "bug parade" in former times. I often got messages like
> this:
>
> We have determined that this report is a new bug and entered the bug
> into our
> internal bug tracking system under Bug Id: 4894530.
>
> You can monitor this bug and look for related issues on The Java Developer
> Connection Bug Parade at:
> http://developer.java.sun.com/developer/bugParade/bugs/4894530.html
>
>
> -Ulf
>
>
> Am 01.05.2009 03:41, Brad Wetmore schrieb:
>> For the "bug parade", were you talking about the bugs.sun.com "bug
>> parade" or the openjdk.java.net Bugzilla instance?
>>
>> Brad
>>
>>
>> Ulf Zibis wrote:
>>> Hi all,
>>>
>>> I also think, that existing tools for externals are very poor,
>>> compared e.g. with NetBeans project.
>>>
>>> Especially on the bug parade I'm missing:
>>> - sophisticated search tools
>>> - saving search profiles
>>> - reopening bugs from external
>>> - attaching resources
>>> - customising the watch list, e.g. displaying the summary in the list
>>> (today only id's are displayed, and you have to open all links, to
>>> see what's inside)
>>>
>>> -Ulf
>>>
>>>
>>> Am 05.03.2009 05:42, Mark Reinhold schrieb:
>>>>> Date: Tue, 03 Mar 2009 13:43:15 -0800
>>>>> From: phil.race@...
>>>>>
>>>>
>>>>
>>>>> As you can see from the email below, there's something of
>>>>> an apparent hole in the description of who should use bugzilla.
>>>>>
>>>>> Can we clarify what's supposed to be the process
>>>>>
>>>>> Specifically if you are external to Sun. but have an openjdk user id
>>>>> either because you are a member of an openjdk group (eg 2d, awt), OR
>>>>> because you have an openjdk project, then should you in fact use
>>>>> bugzilla, since you can't use the Sun internal bugster tool ?
>>>>>
>>>>
>>>> In the long run, people such as Roman who have push rights into the
>>>> JDK 6
>>>> and 7 forests -- and in his case have in fact already pushed changes to
>>>> at least one of those forests, after appropriate review -- should not
>>>> need to use a special process set up primarily for people who
>>>> haven't yet
>>>> earned such rights.
>>>>
>>>> Having said that, Roman is completely right to point out that he can't
>>>> make effective use of bugs.sun.com on his own. There are, moreover,
>>>> other internal tools, e.g., the code-review robot, that aren't (yet)
>>>> available to external developers.
>>>>
>>>> Until such time as more of our internal tools are externalized, and we
>>>> use our Bugzilla for all bugs rather than just for contributions from
>>>> non-Sun developers, I see no harm in using Bugzilla to track changes
>>>> being proposed by such developers even if they do have push rights into
>>>> the appropriate forests.
>>>>
>>>> If there's general agreement on this then I'll arrange for the warning
>>>> header on bugs.openjdk.java.net to be modified accordingly.
>>>>
>>>> - Mark
>>>>
>>>>
>>>>
>>>
>>
>>
>

Re: who should use bugzilla ?

2009-05-01T03:24:49Z

I'm talking about bugs.sun.com, as I remember right, it was even
officially named "bug parade" in former times. I often got messages like
this:

We have determined that this report is a new bug and entered the bug into our
internal bug tracking system under Bug Id: 4894530.

You can monitor this bug and look for related issues on The Java Developer
Connection Bug Parade at:
http://developer.java.sun.com/developer/bugParade/bugs/4894530.html

-Ulf

Am 01.05.2009 03:41, Brad Wetmore schrieb:

> For the "bug parade", were you talking about the bugs.sun.com "bug
> parade" or the openjdk.java.net Bugzilla instance?
>
> Brad
>
>
> Ulf Zibis wrote:
>> Hi all,
>>
>> I also think, that existing tools for externals are very poor,
>> compared e.g. with NetBeans project.
>>
>> Especially on the bug parade I'm missing:
>> - sophisticated search tools
>> - saving search profiles
>> - reopening bugs from external
>> - attaching resources
>> - customising the watch list, e.g. displaying the summary in the list
>> (today only id's are displayed, and you have to open all links, to
>> see what's inside)
>>
>> -Ulf
>>
>>
>> Am 05.03.2009 05:42, Mark Reinhold schrieb:
>>>> Date: Tue, 03 Mar 2009 13:43:15 -0800
>>>> From: phil.race@...
>>>>
>>>
>>>
>>>> As you can see from the email below, there's something of
>>>> an apparent hole in the description of who should use bugzilla.
>>>>
>>>> Can we clarify what's supposed to be the process
>>>>
>>>> Specifically if you are external to Sun. but have an openjdk user id
>>>> either because you are a member of an openjdk group (eg 2d, awt), OR
>>>> because you have an openjdk project, then should you in fact use
>>>> bugzilla, since you can't use the Sun internal bugster tool ?
>>>>
>>>
>>> In the long run, people such as Roman who have push rights into the
>>> JDK 6
>>> and 7 forests -- and in his case have in fact already pushed changes to
>>> at least one of those forests, after appropriate review -- should not
>>> need to use a special process set up primarily for people who
>>> haven't yet
>>> earned such rights.
>>>
>>> Having said that, Roman is completely right to point out that he can't
>>> make effective use of bugs.sun.com on his own. There are, moreover,
>>> other internal tools, e.g., the code-review robot, that aren't (yet)
>>> available to external developers.
>>>
>>> Until such time as more of our internal tools are externalized, and we
>>> use our Bugzilla for all bugs rather than just for contributions from
>>> non-Sun developers, I see no harm in using Bugzilla to track changes
>>> being proposed by such developers even if they do have push rights into
>>> the appropriate forests.
>>>
>>> If there's general agreement on this then I'll arrange for the warning
>>> header on bugs.openjdk.java.net to be modified accordingly.
>>>
>>> - Mark
>>>
>>>
>>>
>>
>
>

Re: who should use bugzilla ?

2009-04-30T18:39:41Z

From a discussion in early March.

Mark Reinhold wrote:
> Until such time as more of our internal tools are externalized, and we
> use our Bugzilla for all bugs rather than just for contributions from
> non-Sun developers, I see no harm in using Bugzilla to track changes
> being proposed by such developers even if they do have push rights into
> the appropriate forests.
>
> If there's general agreement on this then I'll arrange for the warning
> header on bugs.openjdk.java.net to be modified accordingly.

I agree with the "no harm" sentiment. The original intent was for
developers without push rights, but see no reason to restrict it to only
those without push rights.

Since there was no further discussion, I'll assume this is ok, and have
updated the text accordingly.

Brad

P.S. Mark's full response follows:

Mark Reinhold wrote:

>> Date: Tue, 03 Mar 2009 13:43:15 -0800
>> From: phil.race@...
>
>> As you can see from the email below, there's something of
>> an apparent hole in the description of who should use bugzilla.
>>
>> Can we clarify what's supposed to be the process
>>
>> Specifically if you are external to Sun. but have an openjdk user id
>> either because you are a member of an openjdk group (eg 2d, awt), OR
>> because you have an openjdk project, then should you in fact use
>> bugzilla, since you can't use the Sun internal bugster tool ?
>
> In the long run, people such as Roman who have push rights into the JDK 6
> and 7 forests -- and in his case have in fact already pushed changes to
> at least one of those forests, after appropriate review -- should not
> need to use a special process set up primarily for people who haven't yet
> earned such rights.
>
> Having said that, Roman is completely right to point out that he can't
> make effective use of bugs.sun.com on his own. There are, moreover,
> other internal tools, e.g., the code-review robot, that aren't (yet)
> available to external developers.
>
> Until such time as more of our internal tools are externalized, and we
> use our Bugzilla for all bugs rather than just for contributions from
> non-Sun developers, I see no harm in using Bugzilla to track changes
> being proposed by such developers even if they do have push rights into
> the appropriate forests.
>
> If there's general agreement on this then I'll arrange for the warning
> header on bugs.openjdk.java.net to be modified accordingly.
>
> - Mark

webrev wrapper for mq users

2009-04-15T04:44:08Z

#! /bin/bash
#
# Usage: qr patch_name
#
# Run this script inside a hg repo with mq. It will create a webrev for
# the specified patch (or the tip) and sync it to cr.openjdk.java.net

[ "$1" == "--help" ] && { echo Usage: qr [patch]; exit 0; }

[ "$1" != "" ] && hg qgoto $1

BUGID=`hg tip --template {desc} | head -n1 | cut -c 1-7`
AUTHOR=`hg tip --template {author}`
LASTVER=`wget -q -O - http://cr.openjdk.java.net/~$AUTHOR/$BUGID |
perl -e '
$m = -1;
while (<STDIN>) {
if (/webrev\.(\d\d)/) {
if ($1 > $m) {
$m = $1;
}
}
};
print $m;
'`

VER=`perl -e 'printf "%02d", '$LASTVER'+1'`

mkdir -p $BUGID
if [ $LASTVER != "-1" ]; then
mkdir $BUGID/webrev.$LASTVER
wget -q -O $BUGID/webrev.$LASTVER/index.html http://cr.openjdk.java.net/~$AUTHOR/$BUGID/webrev.$LASTVER/index.html
perl -p -i -e 's/<\/head>/<\/head><h3><a href="..\/
webrev.'$VER'">A newer webrev<\/a> is available<\/h3><hr\/>/' $BUGID/
webrev.$LASTVER/index.html
fi

webrev -O -N -r -2
hg tip > $BUGID/.description
hg tip --template {desc} | head -n1 > $BUGID/.title
mv webrev $BUGID/webrev.$VER
mv webrev.zip $BUGID/webrev.$VER.zip

echo http://cr.openjdk.java.net/~$AUTHOR/$BUGID/webrev.$VER
echo Press Ctrl-C to stop. Enter to continue
read

rsync -avz $BUGID cr.openjdk.java.net:

echo http://cr.openjdk.java.net/~$AUTHOR/$BUGID/webrev.$VER
rm -rf $BUGID

Re: Syndication feed available on cr.openjdk.java.net

2009-04-13T19:47:13Z

Hi Max

> I notice a problem with the feed. When the first webrev (webrev.00) is
> created for a bug id, a new item appears in the feed. However, when
> webrev.01 is uploaded, nothing happens. Is this a feature or a bug?

That sounds like a bug. We want everyone to be aware of current
events... and that includes updates to anything previously put out.

I'm checking on it. The update job runs about every 10 minutes, and it
should discover anything new or recently modified under the user
directories.

Tim

Re: Syndication feed available on cr.openjdk.java.net

2009-04-13T19:24:08Z

Hi Tim

I notice a problem with the feed. When the first webrev (webrev.00) is
created for a bug id, a new item appears in the feed. However, when
webrev.01 is uploaded, nothing happens. Is this a feature or a bug?

Thanks
Max

Tim Bell wrote:

> Ongoing updates of postings to cr.openjdk.java.net are now visible via:
>
> http://cr.openjdk.java.net/feed.atom
>
> Feel free to subscribe to this stream it you would like to follow it.
>
> To those publishing webrevs or other materials on cr.openjdk.java.net-
> Please refer to the updated example on the main page:
> http://cr.openjdk.java.net
> for how to customize the title and description fields on your feed
> entries. Default values will be used if necessary, so this step is
> optional and not required.
>
> Feedback is welcomed on web-discuss(at)openjdk.java.net.
>
> Best Regards-
>
> Tim
>

Re: Syndication feed available on cr.openjdk.java.net

2009-04-01T10:41:12Z

On 4/1/2009 9:16 PM Tim Bell wrote:
> I updated the configuration to tag the atom feed to be "text/xml". I
> tested this using Opera on one of our Solaris/SPARC lab servers[2] and
> it seems to be OK. Note that I had to exit the Opera browser and
> restart it before it noticed the change in mime type for that page.
>
> Please let me know if it is not working for you.
I've just tried it, and it worked well. Thank you very much!

> [2]Yes, they build a Solaris/SPARC version, and good for them!
This is actually amazing! I noticed before they had the Solaris/SPARC
version on their download page, but I thought it might be as outdated
as, for instance, their BeOS, QNX, and OS/2 versions are. But they have
the latest Opera 9.64 for Solaris/SPARC. Lovely!

--
best regards,
Anthony

Re: Syndication feed available on cr.openjdk.java.net

2009-04-01T10:16:17Z

Anthony Petrov wrote:

> The feed does not work with the Opera web-browser. I tested Opera 9.64
> on both Linux and Windows: when clicking the RSS orange icon in the
> address bar, the browser presents the .xml content of the feed as a
> plain text instead of subscribing to the feed. I double checked, other
> feeds - like from the blogspot.com - work correctly. Firefox 3, however,
> reads the cr.openjdk feed correctly.
>
> I guess there's either a problem with the http-server settings so that
> it reports an incorrect Content-Type: for the feed, or the generated
> .xml for that feed is slightly invalid/non-quite-standards-conformant.
> Could anyone take a look at the issue please?

Thank you for reporting the problem - and for providing the diagnosis!

This was caused by a configuration change I made in the web server on
cr.ojn to tag most files as "text/plain"[1]. This works well for the
large variety of file extensions presented in webrevs, but as you
reported is wrong for the feed. I guess Opera is checking the mimetype
rather than using the data at the top of the feed, which firefox seems
to do.

I updated the configuration to tag the atom feed to be "text/xml". I
tested this using Opera on one of our Solaris/SPARC lab servers[2] and
it seems to be OK. Note that I had to exit the Opera browser and
restart it before it noticed the change in mime type for that page.

Please let me know if it is not working for you.

Best regards-
Tim Bell

[1]http://mail.openjdk.java.net/pipermail/web-discuss/2009-March/000068.html
[2]Yes, they build a Solaris/SPARC version, and good for them!

Re: Syndication feed available on cr.openjdk.java.net

2009-04-01T05:47:04Z

The feed does not work with the Opera web-browser. I tested Opera 9.64
on both Linux and Windows: when clicking the RSS orange icon in the
address bar, the browser presents the .xml content of the feed as a
plain text instead of subscribing to the feed. I double checked, other
feeds - like from the blogspot.com - work correctly. Firefox 3, however,
reads the cr.openjdk feed correctly.

I guess there's either a problem with the http-server settings so that
it reports an incorrect Content-Type: for the feed, or the generated
.xml for that feed is slightly invalid/non-quite-standards-conformant.
Could anyone take a look at the issue please?

--
best regards,
Anthony

On 03/30/2009 09:55 PM Tim Bell wrote:

RE: OpenJDK Community Code Review server rollout

2009-03-27T11:46:33Z

Mark Wielaard mark at klomp.org wrote:

> Would it be possible to tell the server to give the patches type
> text/plain instead of application/octet-stream like
> webrev.invokedynamic.info does?

Done. My apology for the delay in making what turned out to be a
trivial change. I added entries for file extensions that I could see
people are using on cr.openjdk.java.net, and also set the final default
to "text/plain". Please let me know if I missed anything.

Tim Bell

cr% gdiff lighttpd.conf.old lighttpd.conf
58d57
<
73a73
> ".jar" => "application/zip",
92a93
> ".ad" => "text/plain",
93a95,100
> ".d" => "text/plain",
> ".sh" => "text/plain",
> ".rc" => "text/plain",
> ".bat" => "text/plain",
> ".gmk" => "text/plain",
> ".asm" => "text/plain",
94a102,110
> ".hpp" => "text/plain",
> ".java" => "text/plain",
> ".map" => "text/plain",
> ".out" => "text/plain",
> ".lst" => "text/plain",
> ".list" => "text/plain",
> ".patch" => "text/plain",
> ".policy" => "text/plain",
> ".make" => "text/plain",
100a117
> ".mf" => "text/xml",
111c128,129
< ".tar.bz2" => "application/x-bzip-compressed-tar"
---
> ".tar.bz2" => "application/x-bzip-compressed-tar",
> "" => "text/plain"
112a131,132
> # ^^^^ That last entry is to make the default mime type text/plain
> # tbell Fri Mar 27 11:12:28 PDT 2009

freebsd supports openjdk 6 also

2009-03-19T10:32:08Z

Hello,

Is it possible to add FreeBSD to this page?
http://openjdk.java.net/install/

The procedure to install is this:
su -
cd /usr/ports/java/openjdk6
make install && make clean

Thanks for all the hard work,

Ronald.

Re: who should use bugzilla ?

2009-03-05T03:32:00Z

Hi all,

I also think, that existing tools for externals are very poor, compared
e.g. with NetBeans project.

Especially on the bug parade I'm missing:
- sophisticated search tools
- saving search profiles
- reopening bugs from external
- attaching resources
- customising the watch list, e.g. displaying the summary in the list
(today only id's are displayed, and you have to open all links, to see
what's inside)

-Ulf

Am 05.03.2009 05:42, Mark Reinhold schrieb:

>> Date: Tue, 03 Mar 2009 13:43:15 -0800
>> From: phil.race@...
>>
>
>
>> As you can see from the email below, there's something of
>> an apparent hole in the description of who should use bugzilla.
>>
>> Can we clarify what's supposed to be the process
>>
>> Specifically if you are external to Sun. but have an openjdk user id
>> either because you are a member of an openjdk group (eg 2d, awt), OR
>> because you have an openjdk project, then should you in fact use
>> bugzilla, since you can't use the Sun internal bugster tool ?
>>
>
> In the long run, people such as Roman who have push rights into the JDK 6
> and 7 forests -- and in his case have in fact already pushed changes to
> at least one of those forests, after appropriate review -- should not
> need to use a special process set up primarily for people who haven't yet
> earned such rights.
>
> Having said that, Roman is completely right to point out that he can't
> make effective use of bugs.sun.com on his own. There are, moreover,
> other internal tools, e.g., the code-review robot, that aren't (yet)
> available to external developers.
>
> Until such time as more of our internal tools are externalized, and we
> use our Bugzilla for all bugs rather than just for contributions from
> non-Sun developers, I see no harm in using Bugzilla to track changes
> being proposed by such developers even if they do have push rights into
> the appropriate forests.
>
> If there's general agreement on this then I'll arrange for the warning
> header on bugs.openjdk.java.net to be modified accordingly.
>
> - Mark
>
>
>

Re: who should use bugzilla ?

2009-03-04T20:42:52Z

> Date: Tue, 03 Mar 2009 13:43:15 -0800
> From: phil.race@...

> As you can see from the email below, there's something of
> an apparent hole in the description of who should use bugzilla.
>
> Can we clarify what's supposed to be the process
>
> Specifically if you are external to Sun. but have an openjdk user id
> either because you are a member of an openjdk group (eg 2d, awt), OR
> because you have an openjdk project, then should you in fact use
> bugzilla, since you can't use the Sun internal bugster tool ?

In the long run, people such as Roman who have push rights into the JDK 6
and 7 forests -- and in his case have in fact already pushed changes to
at least one of those forests, after appropriate review -- should not
need to use a special process set up primarily for people who haven't yet
earned such rights.

Having said that, Roman is completely right to point out that he can't
make effective use of bugs.sun.com on his own. There are, moreover,
other internal tools, e.g., the code-review robot, that aren't (yet)
available to external developers.

Until such time as more of our internal tools are externalized, and we
use our Bugzilla for all bugs rather than just for contributions from
non-Sun developers, I see no harm in using Bugzilla to track changes
being proposed by such developers even if they do have push rights into
the appropriate forests.

If there's general agreement on this then I'll arrange for the warning
header on bugs.openjdk.java.net to be modified accordingly.

- Mark

Re: OpenJDK Community Code Review server rollout

2009-03-04T17:52:24Z

[Moving this thread to web-discuss (at) openjdk.java.net]

John Rose wrote:

> Thanks! A couple of RFEs:

Thanks back. BTW - I owe a lot to Dan Price and the OpenSolaris folks
for working out this code review server scheme - what I did was take
their layout and hook it up with our db.ojn server and authentication
scheme. After we got a bunch of Legal approval and other
non-programming issues settled...

> You mention webrev on the root page; can we have a link to it there, as
> there in your rollout Email?

Yes, I will make that information more prominent on the page later
tonight. Jessie (Jean-Christophe Collet) has been doing good work on
the webrev script lately, so you probably want to be running the latest
version:

http://blogs.sun.com/jcc/
http://blogs.sun.com/jcc/resource/webrev

> The webrevs are not very portable in their expanded browsable state:
> There are too many files. I'd like to see an option to upload or
> download a *tgz or *zip bundle as a unit.
>
> It could be fairly simple, with just one bit of magic: Have a private
> ".bundles" subdirectory hierarchy with a background script watching it,
> like ".trashes". Uploading to ".bundles" would cause the archive file
> to be unpacked (relative to top level). Allow both ".bundles" "bundles"
> (w/ & w/o leading dot) also, so that the archive files themselves could
> be left out in public, for easy anonymous downloading.

Good idea, and not so hard to set up. Does anyone else have an opinion
on this feature? I will work on getting this up later this week.

Thanks for the feedback-

Tim

> P.S. The old http://webrev.invokedynamic.info/ site did not supply
> rsync/scp/sftp, so I forced users to upload single *tgz or *zip files
> manually. The virtue of this necessity was that the server uploaded the
> bundles as a unit and then unpacked them locally, saving lots of network
> handshakes.

Yes, that is true, although I don't notice a real bottleneck with the
network. I typically start up a 'scp -r' and then go heat up some water
for tea...

Re: who should use bugzilla ?

2009-03-04T15:54:53Z

On Tue, Mar 3, 2009 at 13:43, Phil Race <Phil.Race@...> wrote:
> Hello Brad and Mark,

> Specifically if you are external to Sun. but have an openjdk user id
> either because you are a member of an openjdk group (eg 2d, awt), OR
> because you have an openjdk project, then should you in fact use
> bugzilla, since you can't use the Sun internal bugster tool ?

I am waiting for an announcement that would allow me to do my first
commit entirely without Sun engineer help.

Martin

who should use bugzilla ?

2009-03-03T13:43:15Z

Hello Brad and Mark,

As you can see from the email below, there's something of
an apparent hole in the description of who should use bugzilla.

Can we clarify what's supposed to be the process

Specifically if you are external to Sun. but have an openjdk user id
either because you are a member of an openjdk group (eg 2d, awt), OR
because you have an openjdk project, then should you in fact use
bugzilla, since you can't use the Sun internal bugster tool ?

-phil.

-------- Original Message --------

Roman Kennke wrote:

>>
>> For the cases where where you have a proposed fix, then use bugzilla, for
>> the ones you don't submitting each of those tests as a bug report into bugs.sun.com
>> is the right thing to do at the moment.
>
> Ok. The announcement also says 'contributions from those developers
> without push permissions'. This is interesting, as it excludes people
> like me, who have push access, but I cannot really make use of
> bugs.sun.com either. So I will continue to send emails instead.

I think the intent is that patches should NOT be sent in email,
as bugzilla is now available to track those patches so that they
don't get lost in the email and its easier to see where we are WRT
to integrating contributions.

So you should use bugzilla for submitting patches, even if you
ultimately push them. Patches already in process likely don't
need to be retrospectively added to bugzilla unless you want to
do that.

-phil.

Re: Privacy recommendation on Bugzilla signup page

2009-02-23T14:26:07Z

Good point. Done.

brad

Mark Reinhold wrote:

> Phil just pointed out the following text on the signup page for our
> Bugzilla:
>
> PRIVACY NOTICE: Bugzilla is an open bug tracking system. Activity on
> most bugs, including email addresses, will be visible to the
> public. We recommend using a secondary account or free web email
> service (such as Gmail, Yahoo, Hotmail, or similar) to avoid
> receiving spam at your primary email address.
>
> I'd like to suggest we remove the final sentence. I don't think we
> want Sun engineers to be using non-Sun e-mail addresses -- especially
> secondary addresses which they might not read very often.
>
> - Mark