Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Andrew John Hughes
gnu_andrew at member.fsf.org
Fri May 15 17:32:14 UTC 2009
2009/5/15 Mark Reinhold <mr at sun.com>:
>> Date: Fri, 15 May 2009 16:30:04 +0100
>> From: Andrew John Hughes <gnu_andrew at member.fsf.org>
>> I was thinking this as I read your mail. It should be easy enough to
>> add this as an #else clause to the existing patch in Sanity.gmk.
>> What's the best way to handle updating the patch, given that the
>> existing patch is a committed changeset? Do I need to somehow revert
>> the changeset or is a pair of changesets feasible?
> 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?
I commit the changes because OpenJDK's documentation seems to suggest
that this is prefered (patch submission says hg export -g is
preferable, webrev does an (f)outgoing search first). Do Sun
engineers usually just have their
patches as uncommitted changes?
> 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...
Is the standard format for such messages documented somewhere?
> (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? ;)
> - 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