2009/5/16 Mark Reinhold <[email protected]>: >> Date: Fri, 15 May 2009 18:32:14 +0100 >> From: Andrew John Hughes <[email protected]> > >> 2009/5/15 Mark Reinhold <[email protected]>: >>> 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
