Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional

Andrew John Hughes gnu_andrew at
Mon May 18 18:17:21 UTC 2009

2009/5/16 Mark Reinhold <mr at>:
>> Date: Fri, 15 May 2009 18:32:14 +0100
>> From: Andrew John Hughes <gnu_andrew at>
>> 2009/5/15 Mark Reinhold <mr at>:
>>> One changeset is best.  You need somehow to revert the changeset
>> Somehow I thought that's what you were going to say.. :)
>> Looks like I can do a hg backout to revert the last changeset, and
>> then create a new one.  What's the preferred repo to work against?
>> jdk7/jdk7?
> The preferred repo is the one into which your change will be pushed.
> In this case I'd suggest jdk7/build so that Xiomara's build testing,
> which runs in the context of the release-engineering system that does
> our product builds, has a chance to catch any problems (which seems
> extremely unlikely in this case).

Ok, new webrev created against jdk7/build:

I presume I need to wait a bit due to the current block on pushes though.

>> I commit the changes because OpenJDK's documentation seems to suggest
>> that this is preferred (patch submission says hg export -g is
>> preferable, webrev does an (f)outgoing search first).
> Ah, I was assuming you were going to push the change in yourself.  If
> you'd rather just submit a patch that's fine too; whichever you prefer.

You're right, I do plan to push the change myself.  I was just using
that as an example of the assumption that the changes would have been
committed prior to patch creation, rather than being local uncommitted

>>                                                        Do Sun
>> engineers usually just have their
>> patches as uncommitted changes?
> No.  My impression (which may be incorrect) is that many Sun engineers
> still aren't all that comfortable slinging patches, so instead they tend
> to work on several different repos/forests, one per change in progress,
> which was a common practice with the old internal TeamWare SCM.

Ah, right -- now it makes sense :)

>>> anyway since it'd need a proper comment, with a Sun bug id, before
>>> being pushed upstream.  (I just created one for you: 6841728.)
>> It had a bug ID, just a Bugzilla one...
> At the moment we're assigning inbound patches a Sun bug id for tracking
> purposes, and still using Sun bug ids uniformly in changeset comments.
> That will change, in time, as part of the Bugzilla migration project.

Understood.  It will be better all round when we we fully migrate.

>> Is the standard format for such messages documented somewhere?

Thanks.  I'd forgotten about the developer guide.  It was been
discussed for a while, but then things seemed to go quiet.  Is it now

>>> (I can't resist pointing out that if you were using Mercurial patch
>>>  queues you could just pop to that patch, edit, re-test, finalize,
>>>  and then push the resulting changeset upstream.)
>> Yeah, but can webrev use patch queues yet? ;)
> There are no mq-specific features in webrev, but since an mq-managed
> patch shows up as a regular changeset there's no reason you couldn't
> create a webrev comparing that changeset to some other one using the
> exicting capabilities of the webrev script.
> - Mark
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (

Support Free Java!
Contribute to GNU Classpath and the OpenJDK

PGP Key: 94EFD9D8 (
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

More information about the build-dev mailing list