Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Andrew John Hughes
gnu_andrew at member.fsf.org
Mon May 18 11:17:21 PDT 2009
2009/5/16 Mark Reinhold <mr at sun.com>:
>> Date: Fri, 15 May 2009 18:32:14 +0100
>> From: Andrew John Hughes <gnu_andrew at member.fsf.org>
>> 2009/5/15 Mark Reinhold <mr at sun.com>:
>>> 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?
> 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
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
More information about the build-dev