From abhi.saha at oracle.com Fri Jul 8 08:03:05 2011 From: abhi.saha at oracle.com (abhi.saha at oracle.com) Date: Fri, 08 Jul 2011 15:03:05 +0000 Subject: hg: jdk7u/jdk7u: 3 new changesets Message-ID: <20110708150306.2F4B747299@hg.openjdk.java.net> Changeset: 8da980eedab6 Author: jeff Date: 2011-06-22 10:09 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/rev/8da980eedab6 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: d91364304d7c Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/rev/d91364304d7c Merge Changeset: ee67ee3bd597 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/rev/ee67ee3bd597 Added tag jdk7-b147 for changeset d91364304d7c ! .hgtags From abhi.saha at oracle.com Fri Jul 8 08:03:13 2011 From: abhi.saha at oracle.com (abhi.saha at oracle.com) Date: Fri, 08 Jul 2011 15:03:13 +0000 Subject: hg: jdk7u/jdk7u/corba: 3 new changesets Message-ID: <20110708150316.35B7C4729B@hg.openjdk.java.net> Changeset: bba0e37d7006 Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/corba/rev/bba0e37d7006 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 73323cb33962 Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/corba/rev/73323cb33962 Merge Changeset: 960011ba4bf2 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/corba/rev/960011ba4bf2 Added tag jdk7-b147 for changeset 73323cb33962 ! .hgtags From abhi.saha at oracle.com Fri Jul 8 08:04:05 2011 From: abhi.saha at oracle.com (abhi.saha at oracle.com) Date: Fri, 08 Jul 2011 15:04:05 +0000 Subject: hg: jdk7u/jdk7u/hotspot: 11 new changesets Message-ID: <20110708150428.453134729D@hg.openjdk.java.net> Changeset: f6ba9007b2c6 Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/f6ba9007b2c6 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 5bb91b0db2c9 Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/5bb91b0db2c9 Merge Changeset: 49d1ee0f1f0c Author: trims Date: 2011-06-21 02:43 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/49d1ee0f1f0c Added tag hs21-b16 for changeset 38fa55e5e792 ! .hgtags Changeset: 782e2bb60c41 Author: kvn Date: 2011-06-20 16:45 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/782e2bb60c41 7052494: Eclipse test fails on JDK 7 b142 Summary: Keep 'ne' test in Counted loop when we can't guarantee during compilation that init < limit. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp + test/compiler/7052494/Test7052494.java Changeset: a3081a3a2b54 Author: never Date: 2011-06-21 09:04 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/a3081a3a2b54 7056380: VM crashes with SIGSEGV in compiled code Summary: code was using andq reg, imm instead of addq addr, imm Reviewed-by: kvn, jrose, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_64.ad Changeset: 393e144bb99b Author: never Date: 2011-06-22 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/393e144bb99b 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb Summary: don't skip receiver when GC'ing compiled invokedynamic callsites Reviewed-by: twisti, kvn, jrose ! src/share/vm/code/nmethod.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp Changeset: b3a485ccfe86 Author: trims Date: 2011-06-23 22:43 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/b3a485ccfe86 Merge Changeset: e9b51b4bdcc7 Author: trims Date: 2011-06-23 22:43 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/e9b51b4bdcc7 7057556: Bump the HS21 build number to 17 Summary: Update the HS21 build number to 17 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 81d815b05abb Author: jrose Date: 2011-06-23 17:14 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/81d815b05abb 7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path Reviewed-by: never ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: 684b3ad7bfbc Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/684b3ad7bfbc Added tag jdk7-b147 for changeset 81d815b05abb ! .hgtags Changeset: 9b0ca45cd756 Author: trims Date: 2011-06-28 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/9b0ca45cd756 Added tag hs21-b17 for changeset 81d815b05abb ! .hgtags From abhi.saha at oracle.com Fri Jul 8 08:06:11 2011 From: abhi.saha at oracle.com (abhi.saha at oracle.com) Date: Fri, 08 Jul 2011 15:06:11 +0000 Subject: hg: jdk7u/jdk7u/jaxp: 3 new changesets Message-ID: <20110708150611.2AC3D4729F@hg.openjdk.java.net> Changeset: eed2486cb10b Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jaxp/rev/eed2486cb10b 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: fc268cd1dd5d Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jaxp/rev/fc268cd1dd5d Merge Changeset: 6c9ac74190a0 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jaxp/rev/6c9ac74190a0 Added tag jdk7-b147 for changeset fc268cd1dd5d ! .hgtags From abhi.saha at oracle.com Fri Jul 8 08:06:18 2011 From: abhi.saha at oracle.com (abhi.saha at oracle.com) Date: Fri, 08 Jul 2011 15:06:18 +0000 Subject: hg: jdk7u/jdk7u/jaxws: 3 new changesets Message-ID: <20110708150618.18ED3472A1@hg.openjdk.java.net> Changeset: 632e38191caa Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jaxws/rev/632e38191caa 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: d13b1f877bb5 Author: lana Date: 2011-06-22 12:41 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jaxws/rev/d13b1f877bb5 Merge Changeset: 2605f832dfbf Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jaxws/rev/2605f832dfbf Added tag jdk7-b147 for changeset d13b1f877bb5 ! .hgtags From abhi.saha at oracle.com Fri Jul 8 08:06:30 2011 From: abhi.saha at oracle.com (abhi.saha at oracle.com) Date: Fri, 08 Jul 2011 15:06:30 +0000 Subject: hg: jdk7u/jdk7u/jdk: 3 new changesets Message-ID: <20110708150719.37DD2472A3@hg.openjdk.java.net> Changeset: cfd7602f5c52 Author: jeff Date: 2011-06-22 10:11 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/cfd7602f5c52 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: f097ca2434b1 Author: lana Date: 2011-06-22 12:41 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/f097ca2434b1 Merge Changeset: 9b8c96f96a0f Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/9b8c96f96a0f Added tag jdk7-b147 for changeset f097ca2434b1 ! .hgtags From abhi.saha at oracle.com Fri Jul 8 08:09:06 2011 From: abhi.saha at oracle.com (abhi.saha at oracle.com) Date: Fri, 08 Jul 2011 15:09:06 +0000 Subject: hg: jdk7u/jdk7u/langtools: 3 new changesets Message-ID: <20110708150915.046B7472A5@hg.openjdk.java.net> Changeset: a72412b148d7 Author: jeff Date: 2011-06-22 10:11 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/a72412b148d7 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 58bc532d6341 Author: lana Date: 2011-06-22 12:41 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/58bc532d6341 Merge Changeset: ce654f4ecfd8 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/ce654f4ecfd8 Added tag jdk7-b147 for changeset 58bc532d6341 ! .hgtags From dalibor.topic at oracle.com Tue Jul 12 17:20:34 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 13 Jul 2011 02:20:34 +0200 Subject: Getting started Message-ID: <4E1CE4D2.50105@oracle.com> Welcome. I'll be sending out a set of draft proposals for repository layout, code review, ground rules, and other fine things mentioned in the Project's draft Q&A soon. They are drafts, so your feedback is very welcome to turn them into something that works well. I'd like to allocate time for feedback on them until Sunday, so that we can have them agreed upon and published on the Project's website and can start accepting fixes into the always open mainline jdk7u repository soon after that. While I am the Moderator of this OpenJDK Project (which under the Bylaws should translate into the Project Lead role), the Technical Lead for the Project is Edvard Wendelin (CC:ed). I'll let Edvard introduce himself, and I'll start sending out the drafts for discussion. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Tue Jul 12 17:37:06 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 13 Jul 2011 02:37:06 +0200 Subject: Draft Ground Rules Message-ID: <4E1CE8B2.5080102@oracle.com> Let's start with the ground rules. They are somewhat inspired in parts by the OpenJDK 6 Process, and try to set the stage for open and transparent development. For example, approval requests for changes submitted to JDK 7 Updates should happen in one central place, to allow the Participants on this list to follow along with the development of the updates. Code reviews, otoh, traditionally have taken place on a variety of openjdk lists, so the draft ground rules take that into consideration. Draft Ground Rules: Rule 0: This process is subject to change. Changes MUST be approved by Project Lead and Technical Lead. Changes considering development in OpenJDK MUST be publicly discussed on the jdk7-dev mailing list prior to approval to allow for public feedback. Project Lead is Dalibor Topic, Technical Lead is Edvard Wendelin. Rule 1: All changes that are not specific to JDK 7 Update MUST go into JDK 8 first. As a special exception, a change MAY go into JDK 7 Update if it is at the same time also proposed for inclusion into JDK 8. Rule 2: The always open mainline JDK 7 Update forest is maintained by the Project Lead. Exceptions to that are e.g. specific release repositories, where the Project Lead MAY delegate that authority. Rule 3: Changes submitted for a JDK 7 Update forest MUST go through code review, and MUST be approved by the maintainer for that forest. The maintainer of a forest MAY delegate that authority, allowing for approvals to happen in a more finely granular fashion - per repository, for example. Rule 4: Maintainer approvals for public JDK 7 Update forests MUST take place on the jdk7u-dev at openjdk.java.net mailing list. Code reviews SHOULD take place on that list - if they take place somewhere else, as part of the approval request a URL for the public code review MUST be provided. Rule 5: A maintainer for a forest MAY pre-approve changes undergoing code review for JDK 8 for commit to their forest in JDK 7 Update. Rule 6: A maintainer for a forest MAY request additional reviews for changes to be performed before it is approved for their forest. Rule 7: A maintainer for a forest SHOULD coordinate with the appropriate stakeholders to determine whether changes are appropriate for their forest. Rule 8: For changes submitted for inclusion into a public JDK 7 Update forest, the corresponding bug tracker entry SHOULD be publicly visible. Rule 9: If the corresponding bug tracker entry is not publicly visible for a change submitted for inclusion into a public JDK 7 Update forest, the submitter SHOULD provide guidance for code review. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From ahughes at redhat.com Wed Jul 13 08:28:58 2011 From: ahughes at redhat.com (Andrew John Hughes) Date: Wed, 13 Jul 2011 16:28:58 +0100 Subject: Getting started In-Reply-To: <4E1CE4D2.50105@oracle.com> References: <4E1CE4D2.50105@oracle.com> Message-ID: <20110713152858.GB16917@shelob.middle-earth.co.uk> On Wed, Jul 13, 2011 at 02:20:34AM +0200, Dalibor Topic wrote: > Welcome. > > I'll be sending out a set of draft proposals for repository layout, code review, ground rules, > and other fine things mentioned in the Project's draft Q&A soon. They are drafts, so your > feedback is very welcome to turn them into something that works well. > > I'd like to allocate time for feedback on them until Sunday, so that we can have them agreed upon > and published on the Project's website and can start accepting fixes into the always open mainline > jdk7u repository soon after that. > This doesn't seem like much time, given it's already Wednesday. That's a maximum of only two working days. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Wed Jul 13 08:33:10 2011 From: ahughes at redhat.com (Andrew John Hughes) Date: Wed, 13 Jul 2011 16:33:10 +0100 Subject: Draft Ground Rules In-Reply-To: <4E1CE8B2.5080102@oracle.com> References: <4E1CE8B2.5080102@oracle.com> Message-ID: <20110713153310.GC16917@shelob.middle-earth.co.uk> On Wed, Jul 13, 2011 at 02:37:06AM +0200, Dalibor Topic wrote: > Let's start with the ground rules. > > They are somewhat inspired in parts by the OpenJDK 6 Process, and try to set the stage for open and transparent development. For example, approval requests for changes submitted to JDK 7 Updates should happen in one central place, to allow the Participants on this list to follow along with the development of the updates. Code reviews, otoh, traditionally have taken place on a variety of openjdk lists, so the draft ground rules take that into consideration. > > Draft Ground Rules: > > Rule 0: This process is subject to change. Changes MUST be approved by Project Lead and Technical Lead. Changes considering development in OpenJDK MUST be publicly discussed on the jdk7-dev mailing list prior to approval to allow for public feedback. Project Lead is Dalibor Topic, Technical Lead is Edvard Wendelin. > +1 to more public discussion. Too many changes are just committed with no public review. > Rule 1: All changes that are not specific to JDK 7 Update MUST go into JDK 8 first. As a special exception, a change MAY go into JDK 7 Update if it is at the same time also proposed for inclusion into JDK 8. > With OpenJDK6, we also required that they had 'soaked' for a sufficient time in OpenJDK7, say one build drop. This ensured that they had been through release integration prior to backport. > Rule 2: The always open mainline JDK 7 Update forest is maintained by the Project Lead. Exceptions to that are e.g. specific release repositories, where the Project Lead MAY delegate that authority. > > Rule 3: Changes submitted for a JDK 7 Update forest MUST go through code review, and MUST be approved by the maintainer for that forest. The maintainer of a forest MAY delegate that authority, allowing for approvals to happen in a more finely granular fashion - per repository, for example. > > Rule 4: Maintainer approvals for public JDK 7 Update forests MUST take place on the jdk7u-dev at openjdk.java.net mailing list. Code reviews SHOULD take place on that list - if they take place somewhere else, as part of the approval request a URL for the public code review MUST be provided. > +1 for this as above. > Rule 5: A maintainer for a forest MAY pre-approve changes undergoing code review for JDK 8 for commit to their forest in JDK 7 Update. > > Rule 6: A maintainer for a forest MAY request additional reviews for changes to be performed before it is approved for their forest. > > Rule 7: A maintainer for a forest SHOULD coordinate with the appropriate stakeholders to determine whether changes are appropriate for their forest. > > Rule 8: For changes submitted for inclusion into a public JDK 7 Update forest, the corresponding bug tracker entry SHOULD be publicly visible. > +1, but what about security issues? > Rule 9: If the corresponding bug tracker entry is not publicly visible for a change submitted for inclusion into a public JDK 7 Update forest, the submitter SHOULD provide guidance for code review. > > cheers, > dalibor topic > -- -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From roger.calnan at oracle.com Wed Jul 13 08:44:40 2011 From: roger.calnan at oracle.com (Roger Calnan) Date: Wed, 13 Jul 2011 08:44:40 -0700 Subject: Draft Ground Rules In-Reply-To: <20110713153310.GC16917@shelob.middle-earth.co.uk> References: <4E1CE8B2.5080102@oracle.com> <20110713153310.GC16917@shelob.middle-earth.co.uk> Message-ID: <4284E388-7E2D-4FBD-9637-D6772F90BC48@oracle.com> >> Rule 8: For changes submitted for inclusion into a public JDK 7 Update forest, the corresponding bug tracker entry SHOULD be publicly visible. >> > > +1, but what about security issues? they should be handled today on a need-to-know basis until the GA of the CPU, with you/redhat being one of the parties who need-to-know. Roger From ahughes at redhat.com Wed Jul 13 09:47:23 2011 From: ahughes at redhat.com (Andrew John Hughes) Date: Wed, 13 Jul 2011 17:47:23 +0100 Subject: Draft Ground Rules In-Reply-To: <4284E388-7E2D-4FBD-9637-D6772F90BC48@oracle.com> References: <4E1CE8B2.5080102@oracle.com> <20110713153310.GC16917@shelob.middle-earth.co.uk> <4284E388-7E2D-4FBD-9637-D6772F90BC48@oracle.com> Message-ID: <20110713164723.GG16917@shelob.middle-earth.co.uk> On Wed, Jul 13, 2011 at 08:44:40AM -0700, Roger Calnan wrote: > >> Rule 8: For changes submitted for inclusion into a public JDK 7 Update forest, the corresponding bug tracker entry SHOULD be publicly visible. > >> > > > > +1, but what about security issues? > > they should be handled today on a need-to-know basis until the GA of the CPU, with you/redhat > being one of the parties who need-to-know. > Sorry, I should have been clearer. I know how things work before the embargo passes. I was referring specifically to bug reports and that, with the current system, these remain blocked after the security release. With the Red Hat bug system, Bugzilla allows us to mark comments & attachments individually as private so a bug report can be exposed but certain details elided from public consumption. I don't know what the current status of the OpenJDK bug system is, but doing something similar seems appropriate for security issues. > Roger -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From roger.calnan at oracle.com Wed Jul 13 10:07:00 2011 From: roger.calnan at oracle.com (Roger Calnan) Date: Wed, 13 Jul 2011 10:07:00 -0700 Subject: Draft Ground Rules In-Reply-To: <20110713164723.GG16917@shelob.middle-earth.co.uk> References: <4E1CE8B2.5080102@oracle.com> <20110713153310.GC16917@shelob.middle-earth.co.uk> <4284E388-7E2D-4FBD-9637-D6772F90BC48@oracle.com> <20110713164723.GG16917@shelob.middle-earth.co.uk> Message-ID: <89D432D9-7B95-4749-B08B-031942FE0E48@oracle.com> > With the Red Hat bug system, Bugzilla allows us to mark comments & > attachments individually as private so a bug report can be exposed but > certain details elided from public consumption. I don't know what the > current status of the OpenJDK bug system is, but doing something > similar seems appropriate for security issues. yes, with the new bug tracking system we need to think through how we do something similar. I believe this is on the list of requirements that Mohan published and so we should track this as part of that, we want to be able to refer to at least a subset of the information and use the bugid to track the changesets etc. Roger From dalibor.topic at oracle.com Wed Jul 13 17:25:28 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 14 Jul 2011 02:25:28 +0200 Subject: Draft Repository Management Message-ID: <4E1E3778.7000206@oracle.com> This is a draft for repository management. It describes the forests we have in the OpenJDK Project, what role they serve, and who gets to push code into them. The basic idea is to provide some transparency into repository creation, making it easy for existing JDK 7 Committers to push approved fixes into the always open JDK 7 Update mainline, while gating push access to the masters a bit more carefully to ensure that they are always in a good shape. Draft Text: Preamble: If you want to add a repository or a forest to JDK 7 Updates, you MUST describe to the Technical Lead why, who'll be syncing it, when and how it should it populated, and how code would flow in and out of it. Decisions on adding or removing repositories and forests in OpenJDK MUST be made on the jdk7u-dev mailing list. Rule 0. The mainline forest is called jdk7u. For specific releases, forests are called jdk7uN, with N being the release version. Integration forests have the suffix '-dev'. Rule 1: jdk7u - Master. The master SHOULD always be buildable on all release platforms. It is used for builds by RE and for testing by SQE. The push rights to the master forest are only available to a limited set of Committers chosen by the Project Lead or the Technical Lead. Rule 2: jdk7u-dev - Integration - always-open mainline forest. Integration schedule is TBD, and will be published on the Project's web page. The push rights to the integration forest are available to current JDK 7 Committers. Rule 3: jdk7uN - (where N is not a CPU) Master for a specific release N. It will be created on demand once we go into Phase 2 for that release. The push rights to the release forest are available to a limited set of Committers chosen by the Project Lead or the Technical Lead. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Wed Jul 13 18:45:37 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 14 Jul 2011 03:45:37 +0200 Subject: Draft Public Code Review Proposal Message-ID: <4E1E4A41.1060101@oracle.com> Next item on my draft list is code review. The proposal below is inspired by the developer guide section on code review, and in part inspired by the processes in OpenJDK 6. It tries to encourage transparency, and getting more eyes on the code, while at the same time allowing established practices, like asking component leads for additional reviews, to continue to work. Public code review: Preamble: The new infrastructure is not ready yet, so we won't switch to it for the next release in OpenJDK (i.e. 7u2, as 7u1 is a CPU) just yet. The process here may change for 7u4. Pre-requisite: Before asking for code review, make sure your fix is applied on the most recent revision of the code you intend to work on, that there are no build errors on the supported platforms for the release you're working on, and that any included or otherwise applicable tests pass without failures on all relevant platforms. If you're not able to build or test on all supported platforms, you MUST let the reviewers know which ones you were able to build and test on, as well as whether you anticipate any issues on the platforms you haven't been able to build and test on. Rule 0: Code reviews for public JDK 7 Update forests MUST be done publicly: Either through e-mail on jdk7u-dev at openjdk.java.net mailing list, or using some other suitable public mechanism. If a code review is not done on the jdk7u-dev at openjdk.java.net mailing list, as part of the approval request for inclusion of the fix into a public JDK 7 Updates forest, which you MUST send to the jdk7u-dev at openjdk.java.net mailing list, a URL for the public code review MUST be provided. Rule 1: If the content of a changeset submitted for review for a public JDK 7 Update forest is the same as the corresponding changeset submitted or committed for JDK 8, then it does not have to be resubmitted. In that case its URL will suffice. Rule 2: If the content of a changeset submitted for review for a public JDK 7 Update forest differs from the corresponding JDK 8 changeset, or if there is no corresponding JDK 8 changeset, then the changeset MUST be submitted publicly for review: * A very small changeset MAY be submitted as a simple patch, as described in http://openjdk.java.net/contribute/ * Other than that, changesets SHOULD be submitted as webrevs on the code review server, cr.openjdk.java.net. * Alternatively, a URL for the webrev of the changeset MAY be provided Rule 3: A changeset submitted for the JDK 7 Update mainline forest (jdk7u) MUST be reviewed by at least one reviewer. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads. Rule 4: A changeset submitted for a JDK 7 Update release forest (like jdk7u2, once it's branched off) MUST be reviewed by at least two reviewers. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Wed Jul 13 19:11:56 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 14 Jul 2011 04:11:56 +0200 Subject: Draft Bulk Changes Proposal Message-ID: <4E1E506C.10902@oracle.com> Another one on my list is a draft for bulk changes. Since some of the components used in JDK 7 come from other places (JAX*, Corba, HSX), they tend to get updated in bulk fashion, and to live in their repositories. Since bulk changes tend to be large, and to be applicable to both JDK 8 and JDK 7, the preferred route is to submit them for inclusion into JDK 7 Updates along or after their submission into JDK 8. Since components that get updated in bulk fashion tend to live in their own repositories in the JDK 7 forest, Rule 0 allows the maintainer to designate forests as open for bulk changes. Bulk changes can be disruptive, so Rule 2 ensures that the forest's maintainer can coordinate with the relevant stakeholders before a bulk change is pushed into a forest, and finally Rule 3 sets expectations regarding quality of submitted bulk changes. Bulk changes: Preamble: An example of bulk changes would be an update to a new HotSpot version, security fixes, or updates to JAXP, JAX-WS, or Corba. Rule 0: A maintainer MAY designate one or more repositories in their forest as open for bulk changes. In that case, the maintainer MUST describe the kind of acceptable bulk changes. Rule 1: Bulk changes that are submitted for a JDK 7 Update forest along with or after their submission into JDK 8 don't require additional code review. Rule 2: Bulk changes, like any other changes submitted to a JDK 7 Update forest, MUST be approved by the forest's maintainer before they can be pushed. Rule 3: The submitter MUST make sure there are no build errors on the supported platforms for the release they're working on, and that any included or otherwise applicable tests pass without failures on all relevant platforms. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Wed Jul 13 19:32:30 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 14 Jul 2011 04:32:30 +0200 Subject: Getting started In-Reply-To: <20110713152858.GB16917@shelob.middle-earth.co.uk> References: <4E1CE4D2.50105@oracle.com> <20110713152858.GB16917@shelob.middle-earth.co.uk> Message-ID: <4E1E553E.4040304@oracle.com> On 7/13/11 5:28 PM, Andrew John Hughes wrote: > On Wed, Jul 13, 2011 at 02:20:34AM +0200, Dalibor Topic wrote: >> I'd like to allocate time for feedback on them until Sunday, so that we can have them agreed upon >> and published on the Project's website and can start accepting fixes into the always open mainline >> jdk7u repository soon after that. >> > > This doesn't seem like much time, given it's already Wednesday. That's > a maximum of only two working days. Yeah. I prefer short and focused discussions with quick decisions, so I'm sending out the drafts in small, bite sized pieces, in hope that we can get through each one them very quickly. The proof will be in the practice. So I'd like to get quick, rough understanding on how this OpenJDK project should work, and then address issues as they show up in practice by using Ground Rule 0 to change processes accordingly. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Wed Jul 13 19:41:44 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 14 Jul 2011 04:41:44 +0200 Subject: Draft Ground Rules In-Reply-To: <20110713153310.GC16917@shelob.middle-earth.co.uk> References: <4E1CE8B2.5080102@oracle.com> <20110713153310.GC16917@shelob.middle-earth.co.uk> Message-ID: <4E1E5768.6050609@oracle.com> On 7/13/11 5:33 PM, Andrew John Hughes wrote: > On Wed, Jul 13, 2011 at 02:37:06AM +0200, Dalibor Topic wrote: >> Rule 1: All changes that are not specific to JDK 7 Update MUST go into JDK 8 first. As a special exception, a change MAY go into JDK 7 Update if it is at the same time also proposed for inclusion into JDK 8. >> > > With OpenJDK6, we also required that they had 'soaked' for a sufficient time in OpenJDK7, say > one build drop. This ensured that they had been through release integration prior to backport. Yeah - since OpenJDK 6 did not have its own early access builds like JDK 7 did, that ensured that changes had seen some love from Oracle and community testing JDK 7 early access builds. With JDK 7 Updates, we'll have early access builds, so it's better to get a completed fix destined for a specific release as early as possible into the always-open mainline. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From David.Holmes at oracle.com Wed Jul 13 22:00:15 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 14 Jul 2011 15:00:15 +1000 Subject: Draft Public Code Review Proposal In-Reply-To: <4E1E4A41.1060101@oracle.com> References: <4E1E4A41.1060101@oracle.com> Message-ID: <4E1E77DF.8050505@oracle.com> Hi Dalibor, On 14/07/2011 11:45 AM, Dalibor Topic wrote: > Next item on my draft list is code review. The proposal below is inspired by the developer guide section on code review, and in part inspired by the processes in OpenJDK 6. It tries to encourage transparency, and getting more eyes on the code, while at the same time allowing established practices, like asking component leads for additional reviews, to continue to work. > > Public code review: > > Preamble: The new infrastructure is not ready yet, so we won't switch to it for the next release in OpenJDK (i.e. 7u2, as 7u1 is a CPU) just yet. The process here may change for 7u4. > > Pre-requisite: Before asking for code review, make sure your fix is applied on the most recent revision of the code you intend to work on, that there are no build errors on the supported platforms for the release you're working on, and that any included or otherwise applicable tests pass without failures on all relevant platforms. If you're not able to build or test on all supported platforms, you MUST let the reviewers know which ones you were able to build and test on, as well as whether you anticipate any issues on the platforms you haven't been able to build and test on. > > Rule 0: Code reviews for public JDK 7 Update forests MUST be done publicly: Either through e-mail on jdk7u-dev at openjdk.java.net mailing list, or using some other suitable public mechanism. If a code review is not done on the jdk7u-dev at openjdk.java.net mailing list, as part of the approval request for inclusion of the fix into a public JDK 7 Updates forest, which you MUST send to the jdk7u-dev at openjdk.java.net mailing list, a URL for the public code review MUST be provided. At present who comprises the set of authors, commiters and reviewers for the jdk7u project? > Rule 1: If the content of a changeset submitted for review for a public JDK 7 Update forest is the same as the corresponding changeset submitted or committed for JDK 8, then it does not have to be resubmitted. In that case its URL will suffice. I don't understand what you mean by resubmitted. Do you just mean that we can give the URL to the original JDK8 webrev? I assume review is still necessary. > Rule 2: If the content of a changeset submitted for review for a public JDK 7 Update forest differs from the corresponding JDK 8 changeset, or if there is no corresponding JDK 8 changeset, then the changeset MUST be submitted publicly for review: > > * A very small changeset MAY be submitted as a simple patch, as described in http://openjdk.java.net/contribute/ > > * Other than that, changesets SHOULD be submitted as webrevs on the code review server, cr.openjdk.java.net. > > * Alternatively, a URL for the webrev of the changeset MAY be provided > > Rule 3: A changeset submitted for the JDK 7 Update mainline forest (jdk7u) MUST be reviewed by at least one reviewer. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads. > > Rule 4: A changeset submitted for a JDK 7 Update release forest (like jdk7u2, once it's branched off) MUST be reviewed by at least two reviewers. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads. So I don't understand how rules 3 and 4 interact. Let's assume that jdk7u exists and we haven't yet forked off jdk7u2. I have a fix that must be in 7u2 so I push to the jdk7u-dev repo. According to the above this requires a single reviewer. When 7u2 repos are created I assume they will contain the current contains of 7u mainline - is that right? Is it after that point that commits to 7u2 require two reviews (presumably because by that stage we anticipate 7u2 is fairly close and so we need to be extra careful when doing commits)? I assume that the approval of the Project and Technical leads are in addition to reviews themselves. What is the process for obtaining approval? I would expect that approval, in principle at least, for a given CR needs to be given upfront, and then again once the final code change is ready. What are the expectations and limitations on placing things into an update release? FYI I have a fix (7039182) that is in 8 and needs to be in 7u2 and I'd like to move on this asap, so don't mind being the initial tester of the new process, as it were. For good measure this is actually a non-public CR so we'll see how that part of the process goes too ;-) Cheers, David Holmes > cheers, > dalibor topic From David.Holmes at oracle.com Wed Jul 13 22:11:02 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 14 Jul 2011 15:11:02 +1000 Subject: Draft Bulk Changes Proposal In-Reply-To: <4E1E506C.10902@oracle.com> References: <4E1E506C.10902@oracle.com> Message-ID: <4E1E7A66.2080502@oracle.com> Hi Dalibor, On 14/07/2011 12:11 PM, Dalibor Topic wrote: > Another one on my list is a draft for bulk changes. Since some of the components used in JDK 7 come from other places (JAX*, Corba, HSX), they tend to get updated in bulk fashion, and to live in their repositories. Since bulk changes tend to be large, and to be applicable to both JDK 8 and JDK 7, the preferred route is to submit them for inclusion into JDK 7 Updates along or after their submission into JDK 8. Since components that get updated in bulk fashion tend to live in their own repositories in the JDK 7 forest, Rule 0 allows the maintainer to designate forests as open for bulk changes. Bulk changes can be disruptive, so Rule 2 ensures that the forest's maintainer can coordinate with the relevant stakeholders before a bulk change is pushed into a forest, and finally Rule 3 sets expectations regarding quality of submitted bulk changes. > > Bulk changes: > > Preamble: An example of bulk changes would be an update to a new HotSpot version, security fixes, or updates to JAXP, JAX-WS, or Corba. > > Rule 0: A maintainer MAY designate one or more repositories in their forest as open for bulk changes. In that case, the maintainer MUST describe the kind of acceptable bulk changes. > > Rule 1: Bulk changes that are submitted for a JDK 7 Update forest along with or after their submission into JDK 8 don't require additional code review. Not clear what this means. Take hotspot as an example. Various fixes and enhancements go into the current hsx forest to be included in the next mainline release (JDK8) as well as the next update releases (6uN and 7uN). When 7u2 for example is in a suitable state of readiness the hsx repository will be forked into a 7u2 repository and that would form the "bulk update" that I assume is being referred to here. But such changes might need additional review to ensure that they apply correctly for the update environment - for example they may need to be conditional on a runtime check of the JDK version. It may not have been obvious at the time of the original commit as to which JDK versions the change has to be applicable to. Cheers, David Holmes > Rule 2: Bulk changes, like any other changes submitted to a JDK 7 Update forest, MUST be approved by the forest's maintainer before they can be pushed. > > Rule 3: The submitter MUST make sure there are no build errors on the supported platforms for the release they're working on, and that any included or otherwise applicable tests pass without failures on all relevant platforms. > > cheers, > dalibor topic From ahughes at redhat.com Thu Jul 14 14:50:38 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 14 Jul 2011 22:50:38 +0100 Subject: Draft Public Code Review Proposal In-Reply-To: <4E1E4A41.1060101@oracle.com> References: <4E1E4A41.1060101@oracle.com> Message-ID: <20110714215038.GF32334@rivendell.middle-earth.co.uk> On 03:45 Thu 14 Jul , Dalibor Topic wrote: > Next item on my draft list is code review. The proposal below is inspired by the developer guide section on code review, and in part inspired by the processes in OpenJDK 6. It tries to encourage transparency, and getting more eyes on the code, while at the same time allowing established practices, like asking component leads for additional reviews, to continue to work. > Public code review: > Preamble: The new infrastructure is not ready yet, so we won't > switch to it for the next release in OpenJDK (i.e. 7u2, as 7u1 is a > CPU) just yet. The process here may change for 7u4. What is this 'CPU'? You refer to it both here and in the last document, but I assume it's not Central Processing Unit. > Pre-requisite: Before asking for code review, make sure your fix is applied on the most recent revision of the code you intend to work on, that there are no build errors on the supported platforms for the release you're working on, and that any included or otherwise applicable tests pass without failures on all relevant platforms. If you're not able to build or test on all supported platforms, you MUST let the reviewers know which ones you were able to build and test on, as well as whether you anticipate any issues on the platforms you haven't been able to build and test on. > These rules are very stringent. I doubt anyone outside Oracle is going to be able to build and test on all platforms. Running the full test suite on any platform is non-trivial and something that should be provided by mainline infrastructure, not something every developer has to set up. > Rule 0: Code reviews for public JDK 7 Update forests MUST be done > publicly: Either through e-mail on jdk7u-dev at openjdk.java.net > mailing list, or using some other suitable public mechanism. If a > code review is not done on the jdk7u-dev at openjdk.java.net mailing > list, as part of the approval request for inclusion of the fix into > a public JDK 7 Updates forest, which you MUST send to the > jdk7u-dev at openjdk.java.net mailing list, a URL for the public code > review MUST be provided. > Rule 1: If the content of a changeset submitted for review for a > public JDK 7 Update forest is the same as the corresponding > changeset submitted or committed for JDK 8, then it does not have to > be resubmitted. In that case its URL will suffice. > Rule 2: If the content of a changeset submitted for review for a public JDK 7 Update forest differs from the corresponding JDK 8 changeset, or if there is no corresponding JDK 8 changeset, then the changeset MUST be submitted publicly for review: > > * A very small changeset MAY be submitted as a simple patch, as described in http://openjdk.java.net/contribute/ > > * Other than that, changesets SHOULD be submitted as webrevs on the code review server, cr.openjdk.java.net. > > * Alternatively, a URL for the webrev of the changeset MAY be provided > What is the reasoning behind continuing to use webrevs? They separate the patch from the discussion and there seems to be no guarantee that they won't just disappear, as they aren't archived with the mails. > Rule 3: A changeset submitted for the JDK 7 Update mainline forest > (jdk7u) MUST be reviewed by at least one reviewer. The maintainer > responsible for approval of the changeset MAY request additional, > specific reviewers to review the changeset, e. g. component leads. > Rule 4: A changeset submitted for a JDK 7 Update release forest > (like jdk7u2, once it's branched off) MUST be reviewed by at least > two reviewers. The maintainer responsible for approval of the > changeset MAY request additional, specific reviewers to review the > changeset, e. g. component leads. > cheers, dalibor topic Cheers, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From roger.calnan at oracle.com Thu Jul 14 15:03:17 2011 From: roger.calnan at oracle.com (Roger Calnan) Date: Thu, 14 Jul 2011 15:03:17 -0700 Subject: Draft Public Code Review Proposal In-Reply-To: <20110714215038.GF32334@rivendell.middle-earth.co.uk> References: <4E1E4A41.1060101@oracle.com> <20110714215038.GF32334@rivendell.middle-earth.co.uk> Message-ID: <1CCA06B1-BD6B-4DA8-89B3-30A53B4E27CF@oracle.com> > Preamble: The new infrastructure is not ready yet, so we won't >> switch to it for the next release in OpenJDK (i.e. 7u2, as 7u1 is a >> CPU) just yet. The process here may change for 7u4. > > What is this 'CPU'? You refer to it both here and in the last > document, but I assume it's not Central Processing Unit. :) Sorry one of the Oracle terms we have been learning to use: Critical Patch Update - essentially a security fix only release. Roger From kelly.ohair at oracle.com Thu Jul 14 15:44:30 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 14 Jul 2011 15:44:30 -0700 Subject: Draft Repository Management In-Reply-To: <4E1E3778.7000206@oracle.com> References: <4E1E3778.7000206@oracle.com> Message-ID: <1B3989DA-D0FF-46EB-A435-DEA4F4DFCEEB@oracle.com> On Jul 13, 2011, at 5:25 PM, Dalibor Topic wrote: > This is a draft for repository management. It describes the forests we have in the OpenJDK Project, what role they serve, and who gets to push code into them. The basic idea is to provide some transparency into repository creation, making it easy for existing JDK 7 Committers to push approved fixes into the always open JDK 7 Update mainline, while gating push access to the masters a bit more carefully to ensure that they are always in a good shape. > > Draft Text: > > Preamble: If you want to add a repository or a forest to JDK 7 Updates, you MUST describe to the Technical Lead why, who'll be syncing it, when and how it should it populated, and how code would flow in and out of it. Decisions on adding or removing repositories and forests in OpenJDK MUST be made on the jdk7u-dev mailing list. > > Rule 0. The mainline forest is called jdk7u. For specific releases, forests are called jdk7uN, with N being the release version. Integration forests have the suffix '-dev'. I like the -dev suffix idea. > > Rule 1: jdk7u - Master. The master SHOULD always be buildable on all release platforms. It is used for builds by RE and for testing by SQE. The push rights to the master forest are only available to a limited set of Committers chosen by the Project Lead or the Technical Lead. > This is http://hg.openjdk.java.net/jdk7u/jdk7u/ right? > Rule 2: jdk7u-dev - Integration - always-open mainline forest. Integration schedule is TBD, and will be published on the Project's web page. The push rights to the integration forest are available to current JDK 7 Committers. > This will be http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ ? > Rule 3: jdk7uN - (where N is not a CPU) Master for a specific release N. It will be created on demand once we go into Phase 2 for that release. The push rights to the release forest are available to a limited set of Committers chosen by the Project Lead or the Technical Lead. (just to clarify, CPU==Critical Patch Update, e.g. 7u1 is a CPU) When not a CPU, e.g. 7u2, it will be http://hg.openjdk.java.net/jdk7u/jdk7u2/ ? Everything under http://hg.openjdk.java.net/jdk7u/ ? -kto > > cheers, > dalibor topic > -- > Oracle > Dalibor Topic | Java F/OSS Ambassador > Phone: +494023646738 | Mobile: +491772664192 > Oracle Java Platform Group > > ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven > > Green Oracle Oracle is committed to developing practices and products that help protect the environment From kelly.ohair at oracle.com Thu Jul 14 15:48:05 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 14 Jul 2011 15:48:05 -0700 Subject: Draft Bulk Changes Proposal In-Reply-To: <4E1E506C.10902@oracle.com> References: <4E1E506C.10902@oracle.com> Message-ID: <369D5216-F5D4-4908-8EFE-E430CDD48B25@oracle.com> On Jul 13, 2011, at 7:11 PM, Dalibor Topic wrote: > Another one on my list is a draft for bulk changes. Since some of the components used in JDK 7 come from other places (JAX*, Corba, HSX), they tend to get updated in bulk fashion, and to live in their repositories. Since bulk changes tend to be large, and to be applicable to both JDK 8 and JDK 7, the preferred route is to submit them for inclusion into JDK 7 Updates along or after their submission into JDK 8. Since components that get updated in bulk fashion tend to live in their own repositories in the JDK 7 forest, Rule 0 allows the maintainer to designate forests as open for bulk changes. Bulk changes can be disruptive, so Rule 2 ensures that the forest's maintainer can coordinate with the relevant stakeholders before a bulk change is pushed into a forest, and finally Rule 3 sets expectations regarding quality of submitted bulk changes. > > Bulk changes: > > Preamble: An example of bulk changes would be an update to a new HotSpot version, security fixes, or updates to JAXP, JAX-WS, or Corba. > > Rule 0: A maintainer MAY designate one or more repositories in their forest as open for bulk changes. In that case, the maintainer MUST describe the kind of acceptable bulk changes. > > Rule 1: Bulk changes that are submitted for a JDK 7 Update forest along with or after their submission into JDK 8 don't require additional code review. > > Rule 2: Bulk changes, like any other changes submitted to a JDK 7 Update forest, MUST be approved by the forest's maintainer before they can be pushed. > > Rule 3: The submitter MUST make sure there are no build errors on the supported platforms for the release they're working on, and that any included or otherwise applicable tests pass without failures on all relevant platforms. Doesn't Rule 3 apply to ALL changes? Or is this really saying that bulk changes should include more testing, like all applicable tests for the components being bulk changed? -kto > > cheers, > dalibor topic > -- > Oracle > Dalibor Topic | Java F/OSS Ambassador > Phone: +494023646738 | Mobile: +491772664192 > Oracle Java Platform Group > > ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven > > Green Oracle Oracle is committed to developing practices and products that help protect the environment From kelly.ohair at oracle.com Thu Jul 14 15:55:56 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 14 Jul 2011 15:55:56 -0700 Subject: Draft Public Code Review Proposal In-Reply-To: <4E1E4A41.1060101@oracle.com> References: <4E1E4A41.1060101@oracle.com> Message-ID: On Jul 13, 2011, at 6:45 PM, Dalibor Topic wrote: > Next item on my draft list is code review. The proposal below is inspired by the developer guide section on code review, and in part inspired by the processes in OpenJDK 6. It tries to encourage transparency, and getting more eyes on the code, while at the same time allowing established practices, like asking component leads for additional reviews, to continue to work. > > Public code review: > > Preamble: The new infrastructure is not ready yet, so we won't switch to it for the next release in OpenJDK (i.e. 7u2, as 7u1 is a CPU) just yet. The process here may change for 7u4. > > Pre-requisite: Before asking for code review, make sure your fix is applied on the most recent revision of the code you intend to work on, that there are no build errors on the supported platforms for the release you're working on, and that any included or otherwise applicable tests pass without failures on all relevant platforms. If you're not able to build or test on all supported platforms, you MUST let the reviewers know which ones you were able to build and test on, as well as whether you anticipate any issues on the platforms you haven't been able to build and test on. > > Rule 0: Code reviews for public JDK 7 Update forests MUST be done publicly: Either through e-mail on jdk7u-dev at openjdk.java.net mailing list, or using some other suitable public mechanism. If a code review is not done on the jdk7u-dev at openjdk.java.net mailing list, as part of the approval request for inclusion of the fix into a public JDK 7 Updates forest, which you MUST send to the jdk7u-dev at openjdk.java.net mailing list, a URL for the public code review MUST be provided. I'm having problems parsing the above sentences. Is it just me? I think I understand what it's basically saying though. > > Rule 1: If the content of a changeset submitted for review for a public JDK 7 Update forest is the same as the corresponding changeset submitted or committed for JDK 8, then it does not have to be resubmitted. In that case its URL will suffice. I have a little issue with this. If it's in jdk8, then you can't just pull the exact same changeset into jdk7u, you can import the same patch and create a new changeset with the same patch, but the patch will be likely applied to different sources, so it's questionable in my mind that it can be called 'the same'. Perhaps the words 'same patch' here? > > Rule 2: If the content of a changeset submitted for review for a public JDK 7 Update forest differs from the corresponding JDK 8 changeset, or if there is no corresponding JDK 8 changeset, then the changeset MUST be submitted publicly for review: > > * A very small changeset MAY be submitted as a simple patch, as described in http://openjdk.java.net/contribute/ > > * Other than that, changesets SHOULD be submitted as webrevs on the code review server, cr.openjdk.java.net. > > * Alternatively, a URL for the webrev of the changeset MAY be provided > > Rule 3: A changeset submitted for the JDK 7 Update mainline forest (jdk7u) MUST be reviewed by at least one reviewer. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads. > > Rule 4: A changeset submitted for a JDK 7 Update release forest (like jdk7u2, once it's branched off) MUST be reviewed by at least two reviewers. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads. Should we require that all changesets applied to the jdk7uN forests, also be applied to the jdk7u forest? -kto > > cheers, > dalibor topic > -- > Oracle > Dalibor Topic | Java F/OSS Ambassador > Phone: +494023646738 | Mobile: +491772664192 > Oracle Java Platform Group > > ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven > > Green Oracle Oracle is committed to developing practices and products that help protect the environment From abhi.saha at oracle.com Fri Jul 15 12:18:48 2011 From: abhi.saha at oracle.com (abhi.saha at oracle.com) Date: Fri, 15 Jul 2011 19:18:48 +0000 Subject: hg: jdk7u/jdk7u: 7057705: can't generate api docs for JDK7 updates Message-ID: <20110715191848.3AABF47468@hg.openjdk.java.net> Changeset: 831f1dadcc35 Author: katleman Date: 2011-06-21 17:30 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/rev/831f1dadcc35 7057705: can't generate api docs for JDK7 updates Reviewed-by: asaha ! make/Defs-internal.gmk From David.Holmes at oracle.com Fri Jul 15 15:23:43 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 16 Jul 2011 08:23:43 +1000 Subject: hg: jdk7u/jdk7u: 7057705: can't generate api docs for JDK7 updates In-Reply-To: <20110715191848.3AABF47468@hg.openjdk.java.net> References: <20110715191848.3AABF47468@hg.openjdk.java.net> Message-ID: <4E20BDEF.7070407@oracle.com> I never saw a code review request for this as per the draft procedures that Dalibor sent out ??? David abhi.saha at oracle.com said the following on 07/16/11 05:18: > Changeset: 831f1dadcc35 > Author: katleman > Date: 2011-06-21 17:30 -0700 > URL: http://hg.openjdk.java.net/jdk7u/jdk7u/rev/831f1dadcc35 > > 7057705: can't generate api docs for JDK7 updates > Reviewed-by: asaha > > ! make/Defs-internal.gmk > From sean.coffey at oracle.com Fri Jul 15 15:40:51 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 15 Jul 2011 23:40:51 +0100 Subject: hg: jdk7u/jdk7u: 7057705: can't generate api docs for JDK7 updates In-Reply-To: <4E20BDEF.7070407@oracle.com> References: <20110715191848.3AABF47468@hg.openjdk.java.net> <4E20BDEF.7070407@oracle.com> Message-ID: <4E20C1F3.2030604@oracle.com> +1 ! Are we all good to start submitting code reviews for 7 updates then ? I also think any draft rules for 7u should be sent to a wider alias for comments. jdk7u-dev contains very few members at the moment. regards, Sean. On 15/07/2011 23:23, David Holmes wrote: > I never saw a code review request for this as per the draft procedures > that Dalibor sent out ??? > > David > > abhi.saha at oracle.com said the following on 07/16/11 05:18: >> Changeset: 831f1dadcc35 >> Author: katleman >> Date: 2011-06-21 17:30 -0700 >> URL: http://hg.openjdk.java.net/jdk7u/jdk7u/rev/831f1dadcc35 >> >> 7057705: can't generate api docs for JDK7 updates >> Reviewed-by: asaha >> >> ! make/Defs-internal.gmk >> From Abhi.Saha at oracle.com Fri Jul 15 16:33:27 2011 From: Abhi.Saha at oracle.com (Abhijit Saha) Date: Fri, 15 Jul 2011 16:33:27 -0700 Subject: Review of 7057705: can't generate api docs for JDK7 updates Message-ID: <4E20CE47.8060402@Oracle.Com> CR: 7057705: can't generate api docs for JDK7 updates Weblink : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057705 Description : Can't generate api docs for JDK7 updates. should be able to generate docs for jdk updates. RE builds always build docs in JDK7, unlike earlier JDK releases. Restriction to NOT build the docs if JDK_UPDATE_VERSION is set should be removed. Targeted forest : http://hg.openjdk.java.net/jdk7u/jdk7u Fix coming from : 7u1 Fix done by : katleman Explanation: This happened since it's a change necessary for RE to be able to start to produce builds for testing. changeset/patch # HG changeset patch # User katleman # Date 1308702629 25200 # Node ID 831f1dadcc357616c50e267413a51c4a4b49d1df # Parent ee67ee3bd597af3097664b1a7d130ffb0b14a1d2 7057705: can't generate api docs for JDK7 updates Reviewed-by: asaha diff --git a/make/Defs-internal.gmk b/make/Defs-internal.gmk --- a/make/Defs-internal.gmk +++ b/make/Defs-internal.gmk @@ -261,12 +261,6 @@ ifndef NO_DOCS ifndef NO_DOCS # Default value (we want javadoc run) GENERATE_DOCS=true - # No DOCS build when JDK_UPDATE_VERSION set on non-OPENJDK builds - ifndef OPENJDK - ifdef JDK_UPDATE_VERSION - GENERATE_DOCS=false - endif - endif # If langtools, corba, jaxp, and jaxws are not being built, # a full jdk javadoc is not possible ifneq ($(BUILD_LANGTOOLS), true) -- Release Lead, Java SE Updates Java Development Group Oracle Corporation. (408)276-7564 From dalibor.topic at oracle.com Fri Jul 15 16:54:01 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Sat, 16 Jul 2011 01:54:01 +0200 Subject: hg: jdk7u/jdk7u: 7057705: can't generate api docs for JDK7 updates In-Reply-To: <4E20C1F3.2030604@oracle.com> References: <20110715191848.3AABF47468@hg.openjdk.java.net> <4E20BDEF.7070407@oracle.com> <4E20C1F3.2030604@oracle.com> Message-ID: <4E20D319.1010509@oracle.com> On 7/16/11 12:40 AM, Se?n Coffey wrote: > +1 ! > > Are we all good to start submitting code reviews for 7 updates then ? Not yet. We need to have the public repository structure and public code review process in place, which, since the feedback period runs until Sunday, can't happen before that. We'll also need to create and populate the jdk7u-dev integration repository, that is proposed in the draft repository management post - that's where approved fixes will go into for mainline. > I also think any draft rules for 7u should be sent to a wider alias for comments. jdk7u-dev contains very few members at the moment. Thanks for pointing that out, please ask relevant parties to join this alias if they haven't done so. The drafts and their discussion are available in this list's archives. There will be more drafts next week (CCC, and a few more things I have on my todo list) with a similar feedback period. cheers, dalibor topic > regards, > Sean. > > On 15/07/2011 23:23, David Holmes wrote: >> I never saw a code review request for this as per the draft procedures that Dalibor sent out ??? >> >> David >> >> abhi.saha at oracle.com said the following on 07/16/11 05:18: >>> Changeset: 831f1dadcc35 >>> Author: katleman >>> Date: 2011-06-21 17:30 -0700 >>> URL: http://hg.openjdk.java.net/jdk7u/jdk7u/rev/831f1dadcc35 >>> >>> 7057705: can't generate api docs for JDK7 updates >>> Reviewed-by: asaha >>> >>> ! make/Defs-internal.gmk >>> -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Fri Jul 15 17:20:09 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Sat, 16 Jul 2011 02:20:09 +0200 Subject: Review of 7057705: can't generate api docs for JDK7 updates In-Reply-To: <4E20CE47.8060402@Oracle.Com> References: <4E20CE47.8060402@Oracle.Com> Message-ID: <4E20D939.8060609@oracle.com> Thanks, Abhijit. I'll provide a bit more background on this change, since it's always a bit scary to see changes flowing into the public repos without having seen them discussed prior to that on a public list, or in other words - it should never happen. As Abhijit writes, this change comes from 7u1, and as I wrote in one of the drafts, that's a CPU - but this is not a security fix, it's 'just' a build fix to allow RE to start producing builds from jdk7u mainline for testing. With that explanation, I'll borrow from Joe Darcy's bag of tricks of dealing with unforeseen circumstances in OpenJDK 6, and retroactively approve this fix, so that RE can produce a build for testing. cheers, dalibor topic On 7/16/11 1:33 AM, Abhijit Saha wrote: > CR: 7057705: can't generate api docs for JDK7 updates > > Weblink : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057705 > > Description : > Can't generate api docs for JDK7 updates. should be able to generate docs for jdk updates. RE builds always build docs in JDK7, unlike earlier JDK releases. Restriction to NOT build the docs if JDK_UPDATE_VERSION is set should be removed. > > Targeted forest : http://hg.openjdk.java.net/jdk7u/jdk7u > > Fix coming from : 7u1 > > Fix done by : katleman > > Explanation: This happened since it's a change necessary for RE to be able to start to produce builds for testing. > > changeset/patch > > # HG changeset patch > # User katleman > # Date 1308702629 25200 > # Node ID 831f1dadcc357616c50e267413a51c4a4b49d1df > # Parent ee67ee3bd597af3097664b1a7d130ffb0b14a1d2 > 7057705: can't generate api docs for JDK7 updates > Reviewed-by: asaha > > diff --git a/make/Defs-internal.gmk b/make/Defs-internal.gmk > --- a/make/Defs-internal.gmk > +++ b/make/Defs-internal.gmk > @@ -261,12 +261,6 @@ ifndef NO_DOCS > ifndef NO_DOCS > # Default value (we want javadoc run) > GENERATE_DOCS=true > - # No DOCS build when JDK_UPDATE_VERSION set on non-OPENJDK builds > - ifndef OPENJDK > - ifdef JDK_UPDATE_VERSION > - GENERATE_DOCS=false > - endif > - endif > # If langtools, corba, jaxp, and jaxws are not being built, > # a full jdk javadoc is not possible > ifneq ($(BUILD_LANGTOOLS), true) > > -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Fri Jul 15 17:34:30 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Sat, 16 Jul 2011 02:34:30 +0200 Subject: hg: jdk7u/jdk7u: 7057705: can't generate api docs for JDK7 updates In-Reply-To: <4E20BDEF.7070407@oracle.com> References: <20110715191848.3AABF47468@hg.openjdk.java.net> <4E20BDEF.7070407@oracle.com> Message-ID: <4E20DC96.9070905@oracle.com> On 7/16/11 12:23 AM, David Holmes wrote: > I never saw a code review request for this as per the draft procedures that Dalibor sent out ??? Thanks, good catch - I asked Abhijit to post the webrev, and description of the change, and provided a bit more background on the change before retroactively approving it. Since the change came from the 7u1 repositories, which is the next CPU, there was no public review of the change as work on security releases doesn't (and can't) happen within OpenJDK. I hope that explains the lack of public review for this specific change. cheers, dalibor topic > David > > abhi.saha at oracle.com said the following on 07/16/11 05:18: >> Changeset: 831f1dadcc35 >> Author: katleman >> Date: 2011-06-21 17:30 -0700 >> URL: http://hg.openjdk.java.net/jdk7u/jdk7u/rev/831f1dadcc35 >> >> 7057705: can't generate api docs for JDK7 updates >> Reviewed-by: asaha >> >> ! make/Defs-internal.gmk >> -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From daniel.daugherty at oracle.com Sat Jul 16 13:24:04 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 16 Jul 2011 14:24:04 -0600 Subject: Draft Ground Rules Message-ID: <4E21F364.4080409@oracle.com> > Rule 0: This process is subject to change. Changes MUST be approved by Project Lead and Technical Lead. Changes considering development in OpenJDK MUST be publicly discussed on the jdk7-dev mailing list prior to approval to allow for public feedback. Project Lead is Dalibor Topic, Technical Lead is Edvard Wendelin. This says "jdk7-dev" should it say "jdk7u-dev" instead? Dan From ahughes at redhat.com Mon Jul 18 16:33:27 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Tue, 19 Jul 2011 00:33:27 +0100 Subject: Review of 7057705: can't generate api docs for JDK7 updates In-Reply-To: <4E20D939.8060609@oracle.com> References: <4E20CE47.8060402@Oracle.Com> <4E20D939.8060609@oracle.com> Message-ID: <20110718233327.GB23991@rivendell.middle-earth.co.uk> On 02:20 Sat 16 Jul , Dalibor Topic wrote: > Thanks, Abhijit. I'll provide a bit more background on this change, since it's always a bit scary to see changes flowing into the public repos without having seen them discussed prior to that on a public list, or in other words - it should never happen. > > As Abhijit writes, this change comes from 7u1, and as I wrote in one of the drafts, that's a CPU - but this is not a security fix, it's 'just' a build fix to allow RE to start producing builds from jdk7u mainline for testing. > > With that explanation, I'll borrow from Joe Darcy's bag of tricks of dealing with unforeseen circumstances in OpenJDK 6, and retroactively approve this fix, so that RE can produce a build for testing. > Does this mean we should already be pulling from the 7u tree? Will there be any more pushes to 7? > cheers, > dalibor topic -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From kumar.x.srinivasan at oracle.COM Mon Jul 18 18:29:35 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 18 Jul 2011 18:29:35 -0700 Subject: Draft Public Code Review Proposal In-Reply-To: References: <4E1E4A41.1060101@oracle.com> Message-ID: <4E24DDFF.1090300@oracle.COM> Hi Dalibor, Kelly, I take it once all this solidifies, there will be a recipe of the steps, posted on http://openjdk.java.net/projects/jdk7u/ ? Thanks Kumar > On Jul 13, 2011, at 6:45 PM, Dalibor Topic wrote: > >> Next item on my draft list is code review. The proposal below is inspired by the developer guide section on code review, and in part inspired by the processes in OpenJDK 6. It tries to encourage transparency, and getting more eyes on the code, while at the same time allowing established practices, like asking component leads for additional reviews, to continue to work. >> >> Public code review: >> >> Preamble: The new infrastructure is not ready yet, so we won't switch to it for the next release in OpenJDK (i.e. 7u2, as 7u1 is a CPU) just yet. The process here may change for 7u4. >> >> Pre-requisite: Before asking for code review, make sure your fix is applied on the most recent revision of the code you intend to work on, that there are no build errors on the supported platforms for the release you're working on, and that any included or otherwise applicable tests pass without failures on all relevant platforms. If you're not able to build or test on all supported platforms, you MUST let the reviewers know which ones you were able to build and test on, as well as whether you anticipate any issues on the platforms you haven't been able to build and test on. >> >> Rule 0: Code reviews for public JDK 7 Update forests MUST be done publicly: Either through e-mail on jdk7u-dev at openjdk.java.net mailing list, or using some other suitable public mechanism. If a code review is not done on the jdk7u-dev at openjdk.java.net mailing list, as part of the approval request for inclusion of the fix into a public JDK 7 Updates forest, which you MUST send to the jdk7u-dev at openjdk.java.net mailing list, a URL for the public code review MUST be provided. > I'm having problems parsing the above sentences. Is it just me? > I think I understand what it's basically saying though. > >> Rule 1: If the content of a changeset submitted for review for a public JDK 7 Update forest is the same as the corresponding changeset submitted or committed for JDK 8, then it does not have to be resubmitted. In that case its URL will suffice. > I have a little issue with this. If it's in jdk8, then you can't just pull the exact same changeset into jdk7u, > you can import the same patch and create a new changeset with the same patch, but the patch will be likely > applied to different sources, so it's questionable in my mind that it can be called 'the same'. > Perhaps the words 'same patch' here? > >> Rule 2: If the content of a changeset submitted for review for a public JDK 7 Update forest differs from the corresponding JDK 8 changeset, or if there is no corresponding JDK 8 changeset, then the changeset MUST be submitted publicly for review: >> >> * A very small changeset MAY be submitted as a simple patch, as described in http://openjdk.java.net/contribute/ >> >> * Other than that, changesets SHOULD be submitted as webrevs on the code review server, cr.openjdk.java.net. >> >> * Alternatively, a URL for the webrev of the changeset MAY be provided >> >> Rule 3: A changeset submitted for the JDK 7 Update mainline forest (jdk7u) MUST be reviewed by at least one reviewer. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads. >> >> Rule 4: A changeset submitted for a JDK 7 Update release forest (like jdk7u2, once it's branched off) MUST be reviewed by at least two reviewers. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads. > Should we require that all changesets applied to the jdk7uN forests, also be applied to the jdk7u forest? > > -kto > >> cheers, >> dalibor topic >> -- >> Oracle >> Dalibor Topic | Java F/OSS Ambassador >> Phone: +494023646738 | Mobile: +491772664192 >> Oracle Java Platform Group >> >> ORACLE Deutschland B.V.& Co. KG | Nagelsweg 55 | 20097 Hamburg >> >> ORACLE Deutschland B.V.& Co. KG >> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRA 95603 >> >> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >> Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven >> >> Green Oracle Oracle is committed to developing practices and products that help protect the environment From suchen.chien at oracle.com Thu Jul 21 12:46:45 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Thu, 21 Jul 2011 19:46:45 +0000 Subject: hg: jdk7u/jdk7u: Added tag jdk7u2-b01 for changeset 831f1dadcc35 Message-ID: <20110721194645.9D93E475BC@hg.openjdk.java.net> Changeset: 91954c06ba1e Author: schien Date: 2011-07-21 12:39 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/rev/91954c06ba1e Added tag jdk7u2-b01 for changeset 831f1dadcc35 ! .hgtags From suchen.chien at oracle.com Thu Jul 21 12:46:52 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Thu, 21 Jul 2011 19:46:52 +0000 Subject: hg: jdk7u/jdk7u/corba: Added tag jdk7u2-b01 for changeset 960011ba4bf2 Message-ID: <20110721194653.10858475BE@hg.openjdk.java.net> Changeset: e1a1c0d72264 Author: schien Date: 2011-07-21 12:39 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/corba/rev/e1a1c0d72264 Added tag jdk7u2-b01 for changeset 960011ba4bf2 ! .hgtags From suchen.chien at oracle.com Thu Jul 21 12:47:46 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Thu, 21 Jul 2011 19:47:46 +0000 Subject: hg: jdk7u/jdk7u/hotspot: Added tag jdk7u2-b01 for changeset 9b0ca45cd756 Message-ID: <20110721194748.3B916475C0@hg.openjdk.java.net> Changeset: 790b18399cd4 Author: schien Date: 2011-07-21 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/790b18399cd4 Added tag jdk7u2-b01 for changeset 9b0ca45cd756 ! .hgtags From suchen.chien at oracle.com Thu Jul 21 12:49:08 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Thu, 21 Jul 2011 19:49:08 +0000 Subject: hg: jdk7u/jdk7u/jaxp: Added tag jdk7u2-b01 for changeset 6c9ac74190a0 Message-ID: <20110721194908.1D70A475C2@hg.openjdk.java.net> Changeset: 4b0c44f2f7f1 Author: schien Date: 2011-07-21 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jaxp/rev/4b0c44f2f7f1 Added tag jdk7u2-b01 for changeset 6c9ac74190a0 ! .hgtags From suchen.chien at oracle.com Thu Jul 21 12:49:14 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Thu, 21 Jul 2011 19:49:14 +0000 Subject: hg: jdk7u/jdk7u/jaxws: Added tag jdk7u2-b01 for changeset 2605f832dfbf Message-ID: <20110721194914.CF92E475C4@hg.openjdk.java.net> Changeset: e94a8b7a9629 Author: schien Date: 2011-07-21 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jaxws/rev/e94a8b7a9629 Added tag jdk7u2-b01 for changeset 2605f832dfbf ! .hgtags From suchen.chien at oracle.com Thu Jul 21 12:49:23 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Thu, 21 Jul 2011 19:49:23 +0000 Subject: hg: jdk7u/jdk7u/jdk: Added tag jdk7u2-b01 for changeset 9b8c96f96a0f Message-ID: <20110721194933.ADADD475C6@hg.openjdk.java.net> Changeset: d1a76a4b1fc3 Author: schien Date: 2011-07-21 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/d1a76a4b1fc3 Added tag jdk7u2-b01 for changeset 9b8c96f96a0f ! .hgtags From suchen.chien at oracle.com Thu Jul 21 12:51:19 2011 From: suchen.chien at oracle.com (suchen.chien at oracle.com) Date: Thu, 21 Jul 2011 19:51:19 +0000 Subject: hg: jdk7u/jdk7u/langtools: Added tag jdk7u2-b01 for changeset ce654f4ecfd8 Message-ID: <20110721195121.B2947475C8@hg.openjdk.java.net> Changeset: 102e79e1e38f Author: schien Date: 2011-07-21 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/102e79e1e38f Added tag jdk7u2-b01 for changeset ce654f4ecfd8 ! .hgtags From dalibor.topic at oracle.com Wed Jul 27 13:47:09 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 27 Jul 2011 13:47:09 -0700 Subject: Draft Ground Rules In-Reply-To: <4E21F364.4080409@oracle.com> References: <4E21F364.4080409@oracle.com> Message-ID: <4E30794D.5020507@oracle.com> On 7/16/11 1:24 PM, Daniel D. Daugherty wrote: >> Rule 0: This process is subject to change. Changes MUST be approved by Project Lead and Technical Lead. Changes considering development in OpenJDK MUST be publicly discussed on the jdk7-dev mailing list prior to approval to allow for public feedback. Project Lead is Dalibor Topic, Technical Lead is Edvard Wendelin. > > This says "jdk7-dev" should it say "jdk7u-dev" instead? Thanks, good catch. Fixed in the now published version. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Wed Jul 27 13:50:36 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 27 Jul 2011 13:50:36 -0700 Subject: Draft Ground Rules In-Reply-To: <4E1CE8B2.5080102@oracle.com> References: <4E1CE8B2.5080102@oracle.com> Message-ID: <4E307A1C.9070408@oracle.com> On 7/12/11 5:37 PM, Dalibor Topic wrote: > Let's start with the ground rules. Thanks everyone for your feedback, I've put the ground rules on the Project web site. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Wed Jul 27 13:53:04 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 27 Jul 2011 13:53:04 -0700 Subject: Draft Repository Management In-Reply-To: <1B3989DA-D0FF-46EB-A435-DEA4F4DFCEEB@oracle.com> References: <4E1E3778.7000206@oracle.com> <1B3989DA-D0FF-46EB-A435-DEA4F4DFCEEB@oracle.com> Message-ID: <4E307AB0.6030500@oracle.com> On 7/14/11 3:44 PM, Kelly O'Hair wrote: > > On Jul 13, 2011, at 5:25 PM, Dalibor Topic wrote: > >> This is a draft for repository management. It describes the forests we have in the OpenJDK Project, what role they serve, and who gets to push code into them. The basic idea is to provide some transparency into repository creation, making it easy for existing JDK 7 Committers to push approved fixes into the always open JDK 7 Update mainline, while gating push access to the masters a bit more carefully to ensure that they are always in a good shape. >> >> Draft Text: >> >> Preamble: If you want to add a repository or a forest to JDK 7 Updates, you MUST describe to the Technical Lead why, who'll be syncing it, when and how it should it populated, and how code would flow in and out of it. Decisions on adding or removing repositories and forests in OpenJDK MUST be made on the jdk7u-dev mailing list. >> >> Rule 0. The mainline forest is called jdk7u. For specific releases, forests are called jdk7uN, with N being the release version. Integration forests have the suffix '-dev'. > > I like the -dev suffix idea. Thanks! > >> >> Rule 1: jdk7u - Master. The master SHOULD always be buildable on all release platforms. It is used for builds by RE and for testing by SQE. The push rights to the master forest are only available to a limited set of Committers chosen by the Project Lead or the Technical Lead. >> > > This is http://hg.openjdk.java.net/jdk7u/jdk7u/ right? Yes. > >> Rule 2: jdk7u-dev - Integration - always-open mainline forest. Integration schedule is TBD, and will be published on the Project's web page. The push rights to the integration forest are available to current JDK 7 Committers. >> > > This will be http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ ? Yes. > >> Rule 3: jdk7uN - (where N is not a CPU) Master for a specific release N. It will be created on demand once we go into Phase 2 for that release. The push rights to the release forest are available to a limited set of Committers chosen by the Project Lead or the Technical Lead. > > (just to clarify, CPU==Critical Patch Update, e.g. 7u1 is a CPU) > > When not a CPU, e.g. 7u2, it will be http://hg.openjdk.java.net/jdk7u/jdk7u2/ ? Yes. > Everything under http://hg.openjdk.java.net/jdk7u/ ? Yeah, the various repos live under the jdk7u hierarchy. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Wed Jul 27 14:53:22 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 27 Jul 2011 14:53:22 -0700 Subject: Draft Repository Management In-Reply-To: <4E1E3778.7000206@oracle.com> References: <4E1E3778.7000206@oracle.com> Message-ID: <4E3088D2.50605@oracle.com> On 7/13/11 5:25 PM, Dalibor Topic wrote: > This is a draft for repository management. It describes the forests we have in the OpenJDK Project, what role they serve, and who gets to push code into them. The basic idea is to provide some transparency into repository creation, making it easy for existing JDK 7 Committers to push approved fixes into the always open JDK 7 Update mainline, while gating push access to the masters a bit more carefully to ensure that they are always in a good shape. > Thanks for the comments - I updated the draft to reflect them and published it on the web site. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Wed Jul 27 15:29:12 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 27 Jul 2011 15:29:12 -0700 Subject: Draft Bulk Changes Proposal In-Reply-To: <4E1E7A66.2080502@oracle.com> References: <4E1E506C.10902@oracle.com> <4E1E7A66.2080502@oracle.com> Message-ID: <4E309138.4010908@oracle.com> On 7/13/11 10:11 PM, David Holmes wrote: > Hi Dalibor, > > On 14/07/2011 12:11 PM, Dalibor Topic wrote: >> Another one on my list is a draft for bulk changes. Since some of the components used in JDK 7 come from other places (JAX*, Corba, HSX), they tend to get updated in bulk fashion, and to live in their repositories. Since bulk changes tend to be large, and to be applicable to both JDK 8 and JDK 7, the preferred route is to submit them for inclusion into JDK 7 Updates along or after their submission into JDK 8. Since components that get updated in bulk fashion tend to live in their own repositories in the JDK 7 forest, Rule 0 allows the maintainer to designate forests as open for bulk changes. Bulk changes can be disruptive, so Rule 2 ensures that the forest's maintainer can coordinate with the relevant stakeholders before a bulk change is pushed into a forest, and finally Rule 3 sets expectations regarding quality of submitted bulk changes. >> >> Bulk changes: >> >> Preamble: An example of bulk changes would be an update to a new HotSpot version, security fixes, or updates to JAXP, JAX-WS, or Corba. >> >> Rule 0: A maintainer MAY designate one or more repositories in their forest as open for bulk changes. In that case, the maintainer MUST describe the kind of acceptable bulk changes. >> >> Rule 1: Bulk changes that are submitted for a JDK 7 Update forest along with or after their submission into JDK 8 don't require additional code review. > > Not clear what this means. Take hotspot as an example. Various fixes and enhancements go into the current hsx forest to be included in the next mainline release (JDK8) as well as the next update releases (6uN and 7uN). When 7u2 for example is in a suitable state of readiness the hsx repository will be forked into a 7u2 repository and that would form the "bulk update" that I assume is being referred to here. But such changes might need additional review to ensure that they apply correctly for the update environment - for example they may need to be conditional on a runtime check of the JDK version. It may not have been obvious at the time of the original commit as to which JDK versions the change has to be applicable to. Thanks, that's a very going point. So I will change that to say Rule 1: Bulk changes that are submitted for a JDK 7 Update forest along with or after their submission into JDK 8 MAY require additional code review, as determined by the forest's maintainer, the Project Lead or the Technical Lead. cheers, dalibor topic > Cheers, > David Holmes > >> Rule 2: Bulk changes, like any other changes submitted to a JDK 7 Update forest, MUST be approved by the forest's maintainer before they can be pushed. >> >> Rule 3: The submitter MUST make sure there are no build errors on the supported platforms for the release they're working on, and that any included or otherwise applicable tests pass without failures on all relevant platforms. >> >> cheers, >> dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Wed Jul 27 15:34:18 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 27 Jul 2011 15:34:18 -0700 Subject: Draft Bulk Changes Proposal In-Reply-To: <369D5216-F5D4-4908-8EFE-E430CDD48B25@oracle.com> References: <4E1E506C.10902@oracle.com> <369D5216-F5D4-4908-8EFE-E430CDD48B25@oracle.com> Message-ID: <4E30926A.2060107@oracle.com> On 7/14/11 3:48 PM, Kelly O'Hair wrote: > > On Jul 13, 2011, at 7:11 PM, Dalibor Topic wrote: > >> Another one on my list is a draft for bulk changes. Since some of the components used in JDK 7 come from other places (JAX*, Corba, HSX), they tend to get updated in bulk fashion, and to live in their repositories. Since bulk changes tend to be large, and to be applicable to both JDK 8 and JDK 7, the preferred route is to submit them for inclusion into JDK 7 Updates along or after their submission into JDK 8. Since components that get updated in bulk fashion tend to live in their own repositories in the JDK 7 forest, Rule 0 allows the maintainer to designate forests as open for bulk changes. Bulk changes can be disruptive, so Rule 2 ensures that the forest's maintainer can coordinate with the relevant stakeholders before a bulk change is pushed into a forest, and finally Rule 3 sets expectations regarding quality of submitted bulk changes. >> >> Bulk changes: >> >> Preamble: An example of bulk changes would be an update to a new HotSpot version, security fixes, or updates to JAXP, JAX-WS, or Corba. >> >> Rule 0: A maintainer MAY designate one or more repositories in their forest as open for bulk changes. In that case, the maintainer MUST describe the kind of acceptable bulk changes. >> >> Rule 1: Bulk changes that are submitted for a JDK 7 Update forest along with or after their submission into JDK 8 don't require additional code review. >> >> Rule 2: Bulk changes, like any other changes submitted to a JDK 7 Update forest, MUST be approved by the forest's maintainer before they can be pushed. >> >> Rule 3: The submitter MUST make sure there are no build errors on the supported platforms for the release they're working on, and that any included or otherwise applicable tests pass without failures on all relevant platforms. > > Doesn't Rule 3 apply to ALL changes? Yes, though I weakened it for the general changes in the code review draft a bit to allow for the scenario of developers outside Oracle not having access to all supported platforms - with bulk changes, though, since those will concern changes coming in bulk from Oracle-led components, that does not seem to be necessary, as developers at Oracle should have access to such platforms at least through internal tools like JPRT. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From poonam.bajaj at oracle.com Thu Jul 28 22:56:51 2011 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Fri, 29 Jul 2011 11:26:51 +0530 Subject: Draft Repository Management In-Reply-To: <4E3088D2.50605@oracle.com> References: <4E1E3778.7000206@oracle.com> <4E3088D2.50605@oracle.com> Message-ID: <4E324BA3.9060208@oracle.com> Hi Dalibor, On the Repository Management page (http://openjdk.java.net/projects/jdk7u/repos.html), the location of 7u integration forest is mentioned. " *Rule 2* jdk7u-dev - Integration - always-open mainline forest. Integration schedule is TBD, and will be published on the Project's web page. The push rights to the integration forest are available to current JDK 7 Committers. The OpenJDK JDK 7 Updates integation forest is located at http://hg.openjdk.java.net/jdk7u/jdk7u-dev/. " But the location http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ is not accessible. Is it correct or the forest has not been created yet ? Thanks, Poonam On 7/28/2011 3:23 AM, Dalibor Topic wrote: > On 7/13/11 5:25 PM, Dalibor Topic wrote: > >> This is a draft for repository management. It describes the forests we have in the OpenJDK Project, what role they serve, and who gets to push code into them. The basic idea is to provide some transparency into repository creation, making it easy for existing JDK 7 Committers to push approved fixes into the always open JDK 7 Update mainline, while gating push access to the masters a bit more carefully to ensure that they are always in a good shape. >> >> > > Thanks for the comments - I updated the draft to reflect them and published it on the web site. > > cheers, > dalibor topic > > > -- Best regards, Poonam Sun, an Oracle company Sun, an Oracle Company Poonam Bajaj | Staff Engineer Phone: +66937451 | Mobile: +9844511366 JVM Sustaining Engineering | Bangalore Green Oracle Oracle is committed to developing practices and products that help protect the environment From erik.trimble at oracle.com Thu Jul 28 23:10:13 2011 From: erik.trimble at oracle.com (Erik Trimble) Date: Thu, 28 Jul 2011 23:10:13 -0700 Subject: Draft Repository Management In-Reply-To: <4E324BA3.9060208@oracle.com> References: <4E1E3778.7000206@oracle.com> <4E3088D2.50605@oracle.com> <4E324BA3.9060208@oracle.com> Message-ID: <4E324EC5.1040709@oracle.com> On 7/28/2011 10:56 PM, Poonam Bajaj wrote: > Hi Dalibor, > > On the Repository Management page > (http://openjdk.java.net/projects/jdk7u/repos.html), the location of > 7u integration forest is mentioned. > > " > *Rule 2* > > jdk7u-dev - Integration - always-open mainline forest. Integration > schedule is TBD, and will be published on the Project's web page. The > push rights to the integration forest are available to current JDK 7 > Committers. > > The OpenJDK JDK 7 Updates integation forest is located at > http://hg.openjdk.java.net/jdk7u/jdk7u-dev/. > " > > But the location http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ is not > accessible. Is it correct or the forest has not been created yet ? > > Thanks, > Poonam > It's not yet created. Will happen sometime in the next week or so. -Erik > > On 7/28/2011 3:23 AM, Dalibor Topic wrote: >> On 7/13/11 5:25 PM, Dalibor Topic wrote: >>> This is a draft for repository management. It describes the forests >>> we have in the OpenJDK Project, what role they serve, and who gets >>> to push code into them. The basic idea is to provide some >>> transparency into repository creation, making it easy for existing >>> JDK 7 Committers to push approved fixes into the always open JDK 7 >>> Update mainline, while gating push access to the masters a bit more >>> carefully to ensure that they are always in a good shape. >>> >> >> Thanks for the comments - I updated the draft to reflect them and >> published it on the web site. >> >> cheers, >> dalibor topic >> >> > -- Erik Trimble Java Platform Group Infrastructure Mailstop: usca22-317 Phone: x67195 Santa Clara, CA Timezone: US/Pacific (UTC-0800) From sean.coffey at oracle.com Fri Jul 29 01:46:32 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 29 Jul 2011 09:46:32 +0100 Subject: Draft Repository Management In-Reply-To: <4E324BA3.9060208@oracle.com> References: <4E1E3778.7000206@oracle.com> <4E3088D2.50605@oracle.com> <4E324BA3.9060208@oracle.com> Message-ID: <4E327368.10902@oracle.com> Poonam, 7u repos are best viewed from http://hg.openjdk.java.net/ I've often wondered why the mercurial webserver doesn't show a sub-forest type view when using the link you've mentioned. e.g http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/ is the forest I'm using. The doc should be updated to avoid confusion though. regards, Sean. On 29/07/2011 06:56, Poonam Bajaj wrote: > Hi Dalibor, > > On the Repository Management page > (http://openjdk.java.net/projects/jdk7u/repos.html), the location of > 7u integration forest is mentioned. > > " > *Rule 2* > > jdk7u-dev - Integration - always-open mainline forest. Integration > schedule is TBD, and will be published on the Project's web page. The > push rights to the integration forest are available to current JDK 7 > Committers. > > The OpenJDK JDK 7 Updates integation forest is located at > http://hg.openjdk.java.net/jdk7u/jdk7u-dev/. > " > > But the location http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ is not > accessible. Is it correct or the forest has not been created yet ? > > Thanks, > Poonam > > > On 7/28/2011 3:23 AM, Dalibor Topic wrote: >> On 7/13/11 5:25 PM, Dalibor Topic wrote: >>> This is a draft for repository management. It describes the forests >>> we have in the OpenJDK Project, what role they serve, and who gets >>> to push code into them. The basic idea is to provide some >>> transparency into repository creation, making it easy for existing >>> JDK 7 Committers to push approved fixes into the always open JDK 7 >>> Update mainline, while gating push access to the masters a bit more >>> carefully to ensure that they are always in a good shape. >>> >> >> Thanks for the comments - I updated the draft to reflect them and >> published it on the web site. >> >> cheers, >> dalibor topic >> >> > From james.holmlund at oracle.com Fri Jul 29 09:29:49 2011 From: james.holmlund at oracle.com (Jim Holmlund) Date: Fri, 29 Jul 2011 09:29:49 -0700 Subject: Draft Repository Management In-Reply-To: <4E327368.10902@oracle.com> References: <4E1E3778.7000206@oracle.com> <4E3088D2.50605@oracle.com> <4E324BA3.9060208@oracle.com> <4E327368.10902@oracle.com> Message-ID: <4E32DFFD.30905@oracle.com> On 7/29/2011 1:46 AM, Se?n Coffey wrote: > Poonam, > > 7u repos are best viewed from http://hg.openjdk.java.net/ > > I've often wondered why the mercurial webserver doesn't show a sub-forest type view when using the > link you've mentioned. e.g http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/ is the forest I'm using. As I read the doc http://openjdk.java.net/projects/jdk7u/repos.html jdk7u/jdk7u is the master and people should not be pushing to it. Erik said that the integration repo(s) to which we should push have not yet been created. It isn't clear to me if we will have just one integration repo, or maybe different ones for core, client, hotspot, etc.) - jjh > > The doc should be updated to avoid confusion though. > regards, > Sean. > > > On 29/07/2011 06:56, Poonam Bajaj wrote: >> Hi Dalibor, >> >> On the Repository Management page (http://openjdk.java.net/projects/jdk7u/repos.html), the >> location of 7u integration forest is mentioned. >> >> " >> *Rule 2* >> >> jdk7u-dev - Integration - always-open mainline forest. Integration schedule is TBD, and will be >> published on the Project's web page. The push rights to the integration forest are available to >> current JDK 7 Committers. >> >> The OpenJDK JDK 7 Updates integation forest is located at >> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/. >> " >> >> But the location http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ is not accessible. Is it correct or >> the forest has not been created yet ? >> >> Thanks, >> Poonam >> >> >> On 7/28/2011 3:23 AM, Dalibor Topic wrote: >>> On 7/13/11 5:25 PM, Dalibor Topic wrote: >>>> This is a draft for repository management. It describes the forests we have in the OpenJDK >>>> Project, what role they serve, and who gets to push code into them. The basic idea is to >>>> provide some transparency into repository creation, making it easy for existing JDK 7 >>>> Committers to push approved fixes into the always open JDK 7 Update mainline, while gating push >>>> access to the masters a bit more carefully to ensure that they are always in a good shape. >>>> >>> >>> Thanks for the comments - I updated the draft to reflect them and published it on the web site. >>> >>> cheers, >>> dalibor topic >>> >>> >> From james.holmlund at oracle.com Fri Jul 29 10:26:48 2011 From: james.holmlund at oracle.com (Jim Holmlund) Date: Fri, 29 Jul 2011 10:26:48 -0700 Subject: Questions on Ground Rules Message-ID: <4E32ED58.6080202@oracle.com> Hi Dalibor, a few questions - The two sentences in Rule 1 of the Ground Rules: http://openjdk.java.net/projects/jdk7u/groundrules.html seem almost contradictory to me. If I have a change that is going to go into both 7u and 8, it appears that I can push the fix to these two repos in either order. Is that true? - If there is an intent that a change destined for both 7u and 8 be pushed into 8 first, how long must one wait after pushing to 8 before pushing to 7u: - not specified - the push to 7u could be done immediately after the push to 8 - until after nightly tests are successfully run on the 8 integration repo to which the fix was pushed - until the fix hits an 8 promoted build - until the fix hits an 8 promoted build and promotion testing has successfully been completed on that promoted build - ?? - The langtools group have some cases where a fix is already in JDK 8, and the patch for 7u is the same, and the webrev for the patch is not in a public place. Would it be ok to just include a link to the JDK 8 changeset in the request for push message, eg: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d6d41563040 Thanks - jjh From erik.trimble at oracle.com Fri Jul 29 13:33:48 2011 From: erik.trimble at oracle.com (Erik Trimble) Date: Fri, 29 Jul 2011 13:33:48 -0700 Subject: Draft Repository Management In-Reply-To: <4E32DFFD.30905@oracle.com> References: <4E1E3778.7000206@oracle.com> <4E3088D2.50605@oracle.com> <4E324BA3.9060208@oracle.com> <4E327368.10902@oracle.com> <4E32DFFD.30905@oracle.com> Message-ID: <4E33192C.8010708@oracle.com> On 7/29/2011 9:29 AM, Jim Holmlund wrote: > > > On 7/29/2011 1:46 AM, Se?n Coffey wrote: >> Poonam, >> >> 7u repos are best viewed from http://hg.openjdk.java.net/ >> >> I've often wondered why the mercurial webserver doesn't show a >> sub-forest type view when using the link you've mentioned. e.g >> http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/ is the forest I'm using. > As I read the doc > http://openjdk.java.net/projects/jdk7u/repos.html > > jdk7u/jdk7u is the master and people should not be pushing to it. > Erik said that the integration repo(s) to which we should push have > not yet been created. It isn't clear to me if we will have just one > integration repo, or maybe different ones for core, client, hotspot, > etc.) > > - jjh > As far as I understand, jdk7u/jdk7u is analogous to the old jdk7/jdk7 forest, and is the RE master which only the Gatekeepers should be pushing to. There also will only be one forest (jdk7u/jdk7u-dev) for everyone to push fixes to (i.e just one Integration forest). There are a couple of reasons: (a) the number of fixes is expected to be significantly lower than the active development branch (jdk8) (b) we'd like to have developers test a bit more themselves before pushing into the Integration repository; that is, since fixes to 7u are lower-risk (i.e. we should be doing almost exclusively bugfixing, with the exception of Hotspot) (c) builds should be further apart than with jdk8, which allows for more time to QA the -dev repository and find any issues All this adds up to making it simpler to have just a single development forest repository, rather than individual group forests. It also means we can dedicate more QA testing hardware to that single forest, rather than spread our resources over multiple forests. Also, as we implement the Build Improvement project, full JDK forest builds will become *significantly* faster, which will allow us to build and test the entire jdk7u-dev forest frequently - ideally, every push from every developer to jdk7u-dev will require a full JDK build&test, but that's the goal; we'll see if that happens. -- Erik Trimble Java Platform Group Infrastructure Mailstop: usca22-317 Phone: x67195 Santa Clara, CA Timezone: US/Pacific (UTC-0800) From erik.trimble at oracle.com Fri Jul 29 13:43:50 2011 From: erik.trimble at oracle.com (Erik Trimble) Date: Fri, 29 Jul 2011 13:43:50 -0700 Subject: Questions on Ground Rules In-Reply-To: <4E32ED58.6080202@oracle.com> References: <4E32ED58.6080202@oracle.com> Message-ID: <4E331B86.400@oracle.com> On 7/29/2011 10:26 AM, Jim Holmlund wrote: > Hi Dalibor, a few questions > - The two sentences in Rule 1 of the Ground Rules: > http://openjdk.java.net/projects/jdk7u/groundrules.html > seem almost contradictory to me. If I have a change that is going > to go into both 7u and 8, it appears that I can push the fix to these > two repos in either order. Is that true? > I do think something needs clarified here. Firstly, the jdk8 and jdk7u forests are Mercurial Forks - there will be NO wholesale pulling/pushing between the two. All work will need to be pushed individually (I expect a fair amount of transplants, though) to each separate forest. > - If there is an intent that a change destined for both 7u and 8 be > pushed into 8 first, how long must one wait after pushing to 8 before > pushing to 7u: > - not specified - the push to 7u could be done immediately after > the push to 8 > - until after nightly tests are successfully run on the 8 > integration repo to which the fix was pushed > - until the fix hits an 8 promoted build > - until the fix hits an 8 promoted build and promotion testing has > successfully been completed on that promoted build > - ?? > We discussed this, and there's no Right Answer. Generally speaking, push the fix into JDK8 first, and let it bake in QA for a bit (at least a night or so). Then push it to JDK7u (if applicable). However, there will be fixes that may belong in ONLY one of the two versions - obviously, push directly to the correct JDK forest. In a few cases, there will be issues that need to be addressed in JDK7u immediately, and can't wait for a JDK8 analysis/fix. The "bake" time for a fix in JDK8 before pushing into JDK7 is subjective, and I don't think we have a good feel as to the correct solution. To a certain extent, it's up to the developer responsible for the fix, as *that* developer will be responsible for pushing the fix independently to both forests. My general feeling is that you should *always* wait until a successful Nightly Testing in JDK8 completed before pushing to JDK7u, and maybe waiting until a full JDK8 promotion is complete before pushing major fixes into JDK7. Finally, build schedules will somewhat dictate how long a fix should bake before being transplanted. Is that clear as mud? :-) -- Erik Trimble Java Platform Group Infrastructure Mailstop: usca22-317 Phone: x67195 Santa Clara, CA Timezone: US/Pacific (UTC-0800) From dalibor.topic at oracle.com Fri Jul 29 17:49:03 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Sat, 30 Jul 2011 02:49:03 +0200 Subject: Questions on Ground Rules In-Reply-To: <4E32ED58.6080202@oracle.com> References: <4E32ED58.6080202@oracle.com> Message-ID: <4E3354FF.9070005@oracle.com> On 7/29/11 7:26 PM, Jim Holmlund wrote: > Hi Dalibor, a few questions > - The two sentences in Rule 1 of the Ground Rules: > http://openjdk.java.net/projects/jdk7u/groundrules.html > seem almost contradictory to me. If I have a change that is going to go into both 7u and 8, it appears that I can push the fix to these two repos in either order. Is that true? Yes, if the change is reviewed & approved for 7u at the same time it is proposed for 8 as well. The rationale behind that the process for getting changes into 8 does not seem to be defined yet, afaict from the JDK 8 web page, so non-Oracle developers need a path to get critical fixes into 7u that doesn't require them to conquer the terra incognita of JDK 8 processes first. In those cases, we'd still like the fix to be on its way into 8 - i.e. proposed for inclusion into 8, following whatever public process for accepting changes are/will be in place there. In addition, as Erik said, there could be scenarios where we need to address an issue in 7u immediately, so allowing that seems like a good idea. There is a difference between allowing it and encouraging it, though, so that's why it's a 'special exception'. > - If there is an intent that a change destined for both 7u and 8 be pushed into 8 first, how long must one wait after pushing to 8 before pushing to 7u: > - not specified - the push to 7u could be done immediately after the push to 8 > - until after nightly tests are successfully run on the 8 integration repo to which the fix was pushed > - until the fix hits an 8 promoted build > - until the fix hits an 8 promoted build and promotion testing has successfully been completed on that promoted build I think that 'it depends': for some changes, I'd expect us to want to see the fix go through more 'bake time' in 8 then for others (and to indicate their preference in the approval mail). > - The langtools group have some cases where a fix is already in JDK 8, and the patch for 7u is the same, and the webrev for the patch is not in a public place. Would it be ok to just include a link to the JDK 8 changeset in the request for push message, eg: > http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d6d41563040 Yes. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From james.holmlund at oracle.com Sat Jul 30 17:16:31 2011 From: james.holmlund at oracle.com (Jim Holmlund) Date: Sat, 30 Jul 2011 17:16:31 -0700 Subject: Questions on Ground Rules In-Reply-To: <4E3354FF.9070005@oracle.com> References: <4E32ED58.6080202@oracle.com> <4E3354FF.9070005@oracle.com> Message-ID: <4E349EDF.3050401@oracle.com> Thanks Dalibor. - jjh On 7/29/2011 5:49 PM, Dalibor Topic wrote: > On 7/29/11 7:26 PM, Jim Holmlund wrote: >> Hi Dalibor, a few questions >> - The two sentences in Rule 1 of the Ground Rules: >> http://openjdk.java.net/projects/jdk7u/groundrules.html >> seem almost contradictory to me. If I have a change that is going to go into both 7u and 8, it appears that I can push the fix to these two repos in either order. Is that true? > Yes, if the change is reviewed& approved for 7u at the same time it is proposed for 8 as well. > > The rationale behind that the process for getting changes into 8 does not seem to be defined yet, afaict from the JDK 8 web page, so non-Oracle developers need a path to get critical fixes into 7u that doesn't require them to conquer the terra incognita of JDK 8 processes first. In those cases, we'd still like the fix to be on its way into 8 - i.e. proposed for inclusion into 8, following whatever public process for accepting changes are/will be in place there. > > In addition, as Erik said, there could be scenarios where we need to address an issue in 7u immediately, so allowing that seems like a good idea. There is a > difference between allowing it and encouraging it, though, so that's why it's a 'special exception'. > >> - If there is an intent that a change destined for both 7u and 8 be pushed into 8 first, how long must one wait after pushing to 8 before pushing to 7u: >> - not specified - the push to 7u could be done immediately after the push to 8 >> - until after nightly tests are successfully run on the 8 integration repo to which the fix was pushed >> - until the fix hits an 8 promoted build >> - until the fix hits an 8 promoted build and promotion testing has successfully been completed on that promoted build > I think that 'it depends': for some changes, I'd expect us to want to see the fix go through more 'bake time' in 8 then for others (and to indicate their preference in the approval mail). > >> - The langtools group have some cases where a fix is already in JDK 8, and the patch for 7u is the same, and the webrev for the patch is not in a public place. Would it be ok to just include a link to the JDK 8 changeset in the request for push message, eg: >> http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d6d41563040 > Yes. > > cheers, > dalibor topic >