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

[Andrew John Hughes]

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

http://fuseyism.com/6841728/webrev.01/

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

>>                                                        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?
>
> http://openjdk.java.net/guide/producingChangeset.html#changesetComment
>

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

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