2009/5/15 Mark Reinhold <m...@sun.com>: >> Date: Fri, 15 May 2009 16:30:04 +0100 >> From: Andrew John Hughes <gnu_and...@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? jdk7/jdk7? 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 > -- 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
