<Swing Dev> Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional

[Mark Reinhold]

> 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?
> 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).

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

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.

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

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

> Is the standard format for such messages documented somewhere?

http://openjdk.java.net/guide/producingChangeset.html#changesetComment

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