From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20138 invoked by alias); 2 Nov 2012 14:54:52 -0000 Received: (qmail 20130 invoked by uid 22791); 2 Nov 2012 14:54:51 -0000 X-SWARE-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 02 Nov 2012 14:54:42 +0000 Received: from zmail17.collab.prod.int.phx2.redhat.com (zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qA2Erllu017728; Fri, 2 Nov 2012 10:53:47 -0400 Date: Fri, 02 Nov 2012 14:54:00 -0000 From: Andrew Hughes To: Mark Wielaard Cc: systemtap@sourceware.org, distro-pkg-dev@openjdk.java.net, Lukas Berk , Jon VanAlten Message-ID: <650449263.4134225.1351868027688.JavaMail.root@redhat.com> In-Reply-To: <1351796745.2848.61.camel@springer.wildebeest.org> Subject: Re: [RFC] Enhanced Garbage Collection Probe Points MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2012-q4/txt/msg00162.txt.bz2 ----- Original Message ----- > On Thu, 2012-11-01 at 14:32 -0400, Jon VanAlten wrote: > > I would also prefer the 7 stuff to go to the forest, but... > > > > > From: "Mark Wielaard" > > > > > > > > > > Adding patches directly to the tree is fine with me. > > > My only hesitation was my own confusion since the default > > > configure/make setup doesn't pick up a patched forest. > > > You don't have that issue with patches, which are directly > > > applied. If we are going for a complete forest setup it > > > might make sense to also add the tapsets and testsuite > > > directly there. > > > > > > I'll try and figure it all out again and also port the existing > > > patches to the forest. Hints and tips appreciated. > > > > So about this patch and 7, I'm getting mixed messages here. > Mark, is this the whole of your patch or only part of it? http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/75982791ddb6 i.e. could that be added to forest and systemtap.patch removed from IcedTea7? > What is the mixed message? I am fine with adding patches directly to > the > forest and even adding the other stuff like the tapsets and the > staptests there. I just don't know the workflow when I would work > against the forest directly and not just have patches in the tree. > And I > just haven't found the time to create a new workflow. I am sure it is > just a different ./configure flag, just haven't figured out which > one. > So, how do people work against the forest directly? What configure > flags > do they use? What does your edit/build/test/commit/pull cycle look > like? > > Basically the only step I seem to miss is how to make sure the tree > is > in sync with what I push to the forest. Somehow I am missing how when > I > commit to the forest the icedtea tree is updated so people who update > their tree get the new patch. Knowing how that works would also help > with making sure the buildbot rebuilds the tree each time the forest > is > changed and not only when a patch is added to the tree. > It's a two stage process: 1. Work against the forest, make sure it builds and then commit. 2. Sync IcedTea7 with the latest forest revisions. For 1, the IcedTea forest (or any OpenJDK tree) can be built with something like: https://bitbucket.org/gnu_andrew/scripts/src/tip/openjdk.sh (you don't need all that; it's designed for maximum flexibility). For stage 2, you need to update the changeset and checksums in IcedTea7. There's a script to do that for you using the latest tip of each repo. See scripts/update_tarballs.sh. You then do a build and, if it's successful with the new tarballs, it can be pushed with the usual ChangeLog. There is no automation of updating IcedTea7 to match the forest as in many cases it requires some manual work. For example, pushing SystemTap to the forest also requires removing the patch in IcedTea7. Likewise, when there is a big upstream merge, bootstrapping often breaks so the bootstrap patches may need to be updated. Also, as updating may also pull in other people's changesets, it's important to announce your intentions on the mailing list before doing so. Pulling in an upstream update that hasn't yet been synced with the forest is going to give you a lot more work to do and possibly duplicate work being done by myself. It may be appropriate to delegate 2 in this case, if you have a fairly minor change but there is a mass of other larger changes coming through too. A typical update for an upstream sync would be: 2012-09-25 Andrew John Hughes * Makefile.am: (OPENJDK_VERSION): Bump to b08. (CORBA_CHANGESET): Update to IcedTea7 forest head. (JAXP_CHANGESET): Likewise. (JAXWS_CHANGESET): Likewise. (JDK_CHANGESET): Likewise. (LANGTOOLS_CHANGESET): Likewise. (OPENJDK_CHANGESET): Likewise. (CORBA_SHA256SUM): Likewise. (JAXP_SHA256SUM): Likewise. (JAXWS_SHA256SUM): Likewise. (JDK_SHA256SUM): Likewise. (LANGTOOLS_SHA256SUM): Likewise. (OPENJDK_SHA256SUM): Likewise. * hotspot.map: Update default to head of IcedTea7 forest HotSpot. * patches/boot/ecj-diamond.patch: Regenerated. Added new cases in javax.crypto.CryptoPermissions, javax.crypto.JceSecurityManager and java.beans.Introspector. * patches/boot/ecj-multicatch.patch: Added new case in sun.tools.jconsole.Resources. * patches/boot/ecj-stringswitch.patch: Regenerated. which reminds me I should update the scripts to better handle the multiple HotSpots we now have to support due to Zero... If you want to have a builder building against the upstream forest rather than the supported set of changesets & checksums, this can be done with 6, 7 & 8. The option --with-openjdk-src-dir can be used to point to a forest checkout. I use this to maintain icedtea6-hg which compiles against upstream OpenJDK6, not a tarball. You may see failures being posted from this when OpenJDK6 is updated and not yet in sync. There's also --enable-hg which does the checkout for you, but this isn't heavily maintained; I don't use it and I believe it still uses the obsolete forest extension. It's also inefficient as it does a completely fresh checkout when it makes more sense to do one manual checkout and reuse it. > Cheers, > > Mark > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07