From lewis.mcgibbney at gmail.com Sat May 10 23:05:38 2014 From: lewis.mcgibbney at gmail.com (Lewis John Mcgibbney) Date: Sat, 10 May 2014 16:05:38 -0700 Subject: [REQUEST] Editor rights to the "OpenJDK Mac OS X Port" wiki Message-ID: Hi Folks, Can I please obtain access to the wiki? The jdk8 at http://hg.openjdk.java.net/jdk8/jdk8 contains the correct instructions and I would like to port these to the wiki. Thank you Lewis -- *Lewis* -------------- next part -------------- An HTML attachment was scrubbed... URL: From iris.clark at oracle.com Tue May 13 23:20:52 2014 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 13 May 2014 16:20:52 -0700 (PDT) Subject: [REQUEST] Editor rights to the "OpenJDK Mac OS X Port" wiki In-Reply-To: References: Message-ID: Hi, Lewis. ? I?m not quite sure which part of the OpenJDK wiki (wiki.openjdk.java.net) you want to update so I?ll give you the general info. ? Each individual wikispace of the OpenJDK wiki are owned by either a Group or Project.? To edit, you need to be registered in the OpenJDK as a member of the owning Group/Project (see the census [1]).? Becoming an Author for a Project is the first step for many.? Instructions for that are here [2[. ? Additional information about the wiki site is available in the FAQ [3]. ? Thanks, Iris Clark ? [1]: http://openjdk.java.net/census [2]: http://openjdk.java.net/projects/#project-author [3]: https://wiki.openjdk.java.net/display/general/FAQ ? From: Lewis John Mcgibbney [mailto:lewis.mcgibbney at gmail.com] Sent: Saturday, May 10, 2014 4:06 PM To: web-discuss at openjdk.java.net Subject: [REQUEST] Editor rights to the "OpenJDK Mac OS X Port" wiki ? Hi Folks, Can I please obtain access to the wiki? The jdk8 at http://HYPERLINK "http://hg.openjdk.java.net/jdk8/jdk8"hg.openjdk.java.net/jdk8/jdk8?contains?the correct instructions and I would like to port these to the wiki. Thank you Lewis -- Lewis -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis.mcgibbney at gmail.com Tue May 13 23:33:01 2014 From: lewis.mcgibbney at gmail.com (Lewis John Mcgibbney) Date: Tue, 13 May 2014 16:33:01 -0700 Subject: [REQUEST] Editor rights to the "OpenJDK Mac OS X Port" wiki In-Reply-To: References: Message-ID: Hi Iris, Thank you very much. Lewis On Tue, May 13, 2014 at 4:20 PM, Iris Clark wrote: > Hi, Lewis. > > > > I?m not quite sure which part of the OpenJDK wiki (wiki.openjdk.java.net) > you want to update so I?ll give you the general info. > > > > Each individual wikispace of the OpenJDK wiki are owned by either a Group > or Project. To edit, you need to be registered in the OpenJDK as a member > of the owning Group/Project (see the census [1]). Becoming an Author for a > Project is the first step for many. Instructions for that are here [2[. > > > > Additional information about the wiki site is available in the FAQ [3]. > > > > Thanks, > > Iris Clark > > > > [1]: http://openjdk.java.net/census > > [2]: http://openjdk.java.net/projects/#project-author > > [3]: https://wiki.openjdk.java.net/display/general/FAQ > > > > *From:* Lewis John Mcgibbney [mailto:lewis.mcgibbney at gmail.com] > *Sent:* Saturday, May 10, 2014 4:06 PM > *To:* web-discuss at openjdk.java.net > *Subject:* [REQUEST] Editor rights to the "OpenJDK Mac OS X Port" wiki > > > > Hi Folks, > > Can I please obtain access to the wiki? > > The jdk8 at http://hg.openjdk.java.net/jdk8/jdk8 contains the correct > instructions and I would like to port these to the wiki. > > Thank you > Lewis > > > -- > *Lewis* > -- *Lewis* -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Mon May 19 22:00:40 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 19 May 2014 15:00:40 -0700 Subject: Planetjdk.org is down In-Reply-To: References: Message-ID: <20140519150040.867506@eggemoggin.niobe.net> 2014/4/21 0:05 -0700, linuxhippy at gmail.com: > About a week ago planetjdk.org went down, are there any plans to bring > it back up? I've always found it useful to get an idea of the ongoing > efforts around openjdk. It's back. (One last casualty of the recent server migration ...) - Mark From aleksey.shipilev at oracle.com Tue May 20 13:04:57 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 20 May 2014 17:04:57 +0400 Subject: Links style Message-ID: <537B52F9.1020602@oracle.com> Hi there, UX question: can we please reconsider the links style on OpenJDK website? Most of my users (and me included) are arguably colorblind and/or having bad screens, because we can hardly see two (visited) links on http://cr.openjdk.java.net/~shade/scratch/oj-web/oj-current.png. I think there are two things which can help: a) Ignore visited links, and draw the links in their original color, see http://cr.openjdk.java.net/~shade/scratch/oj-web/oj-samecolor.png; granted, it would be nicer to segregate visited/non-visited links, but I don't know if the color choices were because of some consistent style. b) Get the underline back when the link is hovered over; that gets back the "tactile" feedback that we are dealing with links, see http://cr.openjdk.java.net/~shade/scratch/oj-web/oj-selected.png. See the sample patch below. Thanks, -Aleksey. $ hg diff etc/ diff -r f8ecef8d8517 etc/page.css --- a/etc/page.css Mon May 19 15:33:47 2014 -0700 +++ b/etc/page.css Tue May 20 16:55:36 2014 +0400 @@ -7,8 +7,8 @@ PRE { font-size: smaller; } A { text-decoration: none; } A:link { color: #437291; } -A:visited { color: #666666; } -A[href]:hover { color: #e76f00; } +A:visited { color: #437291; } +A[href]:hover { color: #e76f00; text-decoration: underline; } A IMG { border-width: 0px; } IMG { background: white; } From tim.bell at oracle.com Tue May 20 16:59:08 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 20 May 2014 09:59:08 -0700 Subject: Fwd: openjdk build pages In-Reply-To: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> Message-ID: <537B89DC.3070304@oracle.com> Forwarding for an OpenJDK member who contacted me offline: -------- Original Message -------- Looks like someone needs to update these pages: http://openjdk.java.net/groups/build/ http://openjdk.java.net/projects/build-infra/ Oh, by the way. The front page only lists bundles for 6, 7, and 7u, no 8 or 8u??? -------- Original Message -------- Tim From iris.clark at oracle.com Tue May 20 17:07:54 2014 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 20 May 2014 10:07:54 -0700 (PDT) Subject: openjdk build pages In-Reply-To: <537B89DC.3070304@oracle.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> Message-ID: > Oh, by the way. The front page only lists bundles for 6, 7, and 7u, no 8 or 8u??? I don't think we have source bundles for 8 or 8u. Did I miss something? Thanks, iris From kellyohair at gmail.com Tue May 20 17:17:38 2014 From: kellyohair at gmail.com (Kelly O'Hair) Date: Tue, 20 May 2014 10:17:38 -0700 Subject: openjdk build pages In-Reply-To: References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> Message-ID: <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> Oh that's fine, I just wondered why 8 was missing. I never liked or used the bundles anyway. ;) -kto On May 20, 2014, at 10:07 AM, Iris Clark wrote: >> Oh, by the way. The front page only lists bundles for 6, 7, and 7u, no 8 or 8u??? > > I don't think we have source bundles for 8 or 8u. Did I miss something? > > Thanks, > iris From Ralf.Herzog at mail.com Tue May 20 17:42:03 2014 From: Ralf.Herzog at mail.com (Ralf Herzog) Date: Tue, 20 May 2014 19:42:03 +0200 Subject: OpenJDK homepage link typo Message-ID: <537B93EB.20101@mail.com> Hello, there is a link mistake on the homepage in the middle which should point to the "source bundle" page. I found there are four slashes after the http-scheme. Chrome and FF do it well but Opera fails. Anyhow, this is an issue. Many greetings, Ralf From dalibor.topic at oracle.com Tue May 20 17:45:36 2014 From: dalibor.topic at oracle.com (dalibor.topic at oracle.com) Date: Tue, 20 May 2014 19:45:36 +0200 Subject: openjdk build pages In-Reply-To: <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> Message-ID: There are no source bundles for 8u. I guess for 8 we could point to the RI source bundle, but I think it's easiest to simply get the source from the corresponding hg forests anyway. -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile:+491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment > On 20.05.2014, at 19:17, Kelly O'Hair wrote: > > Oh that's fine, I just wondered why 8 was missing. I never liked or used the bundles anyway. ;) > > -kto > > On May 20, 2014, at 10:07 AM, Iris Clark wrote: > >>> Oh, by the way. The front page only lists bundles for 6, 7, and 7u, no 8 or 8u??? >> >> I don't think we have source bundles for 8 or 8u. Did I miss something? >> >> Thanks, >> iris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iris.clark at oracle.com Tue May 20 17:53:15 2014 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 20 May 2014 10:53:15 -0700 (PDT) Subject: OpenJDK homepage link typo In-Reply-To: <537B93EB.20101@mail.com> References: <537B93EB.20101@mail.com> Message-ID: Hi, Ralf. Thanks for pointing this out. I'll fix it. iris -----Original Message----- From: Ralf Herzog [mailto:Ralf.Herzog at mail.com] Sent: Tuesday, May 20, 2014 10:42 AM To: web-discuss at openjdk.java.net Subject: OpenJDK homepage link typo Hello, there is a link mistake on the homepage in the middle which should point to the "source bundle" page. I found there are four slashes after the http-scheme. Chrome and FF do it well but Opera fails. Anyhow, this is an issue. Many greetings, Ralf From omajid at redhat.com Tue May 20 18:22:59 2014 From: omajid at redhat.com (Omair Majid) Date: Tue, 20 May 2014 14:22:59 -0400 Subject: openjdk build pages In-Reply-To: <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> Message-ID: <20140520182259.GE2672@redhat.com> Hi, * Kelly O'Hair [2014-05-20 13:17]: > Oh that's fine, I just wondered why 8 was missing. I never liked or > used the bundles anyway. ;) > > I don't think we have source bundles for 8 or 8u. Did I miss something? Speaking as someone who maintains 8u in a Linux distribution, we would love to use official source bundles for 8u. Most packaging systems in Linux start from an upstream tarball (what OpenJDK calls source bundled) [1][2][3] to build and package the software. If an upstream project, like OpenJDK, does not publish official source bundles, then we have to create it manually, which is error prone and can be different from what others may see when they clone the repositories. It also makes it harder to verify authenticity of source bundles in the distribution. In other words, please do consider publishing source bundles for 8u! Thanks, Omair [1] https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#Referencing_Source [2] https://wiki.debian.org/IntroDebianPackaging#Three_central_concepts [3] http://en.opensuse.org/SourceUrls -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From dalibor.topic at oracle.com Wed May 21 09:15:26 2014 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 21 May 2014 11:15:26 +0200 Subject: openjdk build pages In-Reply-To: <20140520182259.GE2672@redhat.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> Message-ID: <537C6EAE.7050006@oracle.com> Actually, I think that for 7u60 (and 7u80) we need to move in the other direction, and not publish separate source bundles from the source code that's already in the Project's Mercurial repositories. Beside being potentially error prone, the trouble I see with providing source bundles for update releases is that because there are update releases we work on as part of OpenJDK (like 7u40), and update releases that we can't work on as part of OpenJDK (like 7u55), and accordingly publish source bundles for the former but not for the latter, there is a regular source of confusion whether a source bundle exists for a release, or not, whether the update project tracks the latest development, etc. etc. etc. The added complexity provides little benefit, and the simplest way to remove the complexity is to remove the issue causing it, and educate users to use the source ... directly from the respective source repository. cheers, dalibor topic On 20.05.2014 20:22, Omair Majid wrote: > Hi, > > * Kelly O'Hair [2014-05-20 13:17]: >> Oh that's fine, I just wondered why 8 was missing. I never liked or >> used the bundles anyway. ;) > >>> I don't think we have source bundles for 8 or 8u. Did I miss something? > > Speaking as someone who maintains 8u in a Linux distribution, we would > love to use official source bundles for 8u. > > Most packaging systems in Linux start from an upstream tarball (what > OpenJDK calls source bundled) [1][2][3] to build and package the > software. If an upstream project, like OpenJDK, does not publish > official source bundles, then we have to create it manually, which is > error prone and can be different from what others may see when they > clone the repositories. It also makes it harder to verify authenticity > of source bundles in the distribution. > > In other words, please do consider publishing source bundles for 8u! > > Thanks, > Omair > > [1] https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#Referencing_Source > [2] https://wiki.debian.org/IntroDebianPackaging#Three_central_concepts > [3] http://en.opensuse.org/SourceUrls > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From iris.clark at oracle.com Wed May 21 20:44:39 2014 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 21 May 2014 13:44:39 -0700 (PDT) Subject: OpenJDK homepage link typo In-Reply-To: <537B93EB.20101@mail.com> References: <537B93EB.20101@mail.com> Message-ID: <52772906-005c-4e4d-b93c-b1a386e2cf47@default> Hi, Ralf. Fixed. Thanks again, iris -----Original Message----- From: Ralf Herzog [mailto:Ralf.Herzog at mail.com] Sent: Tuesday, May 20, 2014 10:42 AM To: web-discuss at openjdk.java.net Subject: OpenJDK homepage link typo Hello, there is a link mistake on the homepage in the middle which should point to the "source bundle" page. I found there are four slashes after the http-scheme. Chrome and FF do it well but Opera fails. Anyhow, this is an issue. Many greetings, Ralf From omajid at redhat.com Wed May 21 23:44:55 2014 From: omajid at redhat.com (Omair Majid) Date: Wed, 21 May 2014 19:44:55 -0400 Subject: openjdk build pages In-Reply-To: <537C6EAE.7050006@oracle.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> Message-ID: <20140521234454.GF3957@redhat.com> * dalibor topic [2014-05-21 05:15]: > Actually, I think that for 7u60 (and 7u80) we need to move in the other > direction, and not publish separate source bundles from the source code > that's already in the Project's Mercurial repositories. I encourage you to think again. The source code system used by OpenJDK (hg trees) is not straight-forward to work with for packagers, and needs non-standard tools, like the trees extension, to fetch complete and consistent things. Source bundles are really easy to work with as a packager. You know you got something consistent that works and don't have to mess around with source code control systems checking out various repositories and tags to find the 'right' source. > Beside being potentially error prone, I am not sure I understand. Surely you can write a script that grabs the right tags from the right forests to create a tarball. I could do it, if I knew exactly which forests and tags contain the right stuff (and could upload it somewhere on openjdk.java.net). In fact, I have something generic already written [1]. Feel free to use it. > and update releases that we can't work on as part of OpenJDK (like > 7u55), I am not sure I follow. If you can commit the source to the repository and tag it, why can't you create a source bundle for those tags? > The added complexity provides little benefit, and the simplest way to remove > the complexity is to remove the issue causing it, and educate users to use > the source ... directly from the respective source repository. I respectfully disagree with your solution. If not providing source bundles causes confusion, wouldn't the right fix be to provide source bundles? As for benefit, just today I saw people asking on #openjdk about where to get source bundles. And they complained that using source control to get a release bundles is too hard (and shouldn't be necessary). Also, if you think users have problems distinguishing 7u60 from 7u55, can you imagine the problems they will have trying to find the real/final tag for 7u55 in the repos? And how some tags do not exist in some repos at some points in time? [2]. Thanks, Omair [1] http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/generate_source_tarball.sh [2] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008969.html -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From martinrb at google.com Thu May 22 01:38:34 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 21 May 2014 18:38:34 -0700 Subject: openjdk build pages In-Reply-To: <20140521234454.GF3957@redhat.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> Message-ID: A slight tangent, but maybe y'all could expand the URLs that allow you to download an entire repo to make this particular way of grabbing bundles more convenient: 1. In addition to the various labels like "jdk7u40-b62" that include a build number, when jdk7u40 is finally released, simply add a tag "jdk7u40" that is the true final released jdk7u40. It would point to the same revision as the last build, presumably jdk7u40-b62". This allows you to download via URL, e.g. http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/archive/jdk7u40.zip 2. (some hg hacking required) Expand the per-repo URLs to download all the repos with one URL, e.g. http://hg.openjdk.java.net/jdk7u/jdk7u/whole-tree/archive/jdk7u40.zip On Wed, May 21, 2014 at 4:44 PM, Omair Majid wrote: > * dalibor topic [2014-05-21 05:15]: > > Actually, I think that for 7u60 (and 7u80) we need to move in the other > > direction, and not publish separate source bundles from the source code > > that's already in the Project's Mercurial repositories. > > I encourage you to think again. The source code system used by OpenJDK > (hg trees) is not straight-forward to work with for packagers, and needs > non-standard tools, like the trees extension, to fetch complete and > consistent things. > > Source bundles are really easy to work with as a packager. You know you > got something consistent that works and don't have to mess around with > source code control systems checking out various repositories and tags > to find the 'right' source. > > > Beside being potentially error prone, > > I am not sure I understand. Surely you can write a script that grabs the > right tags from the right forests to create a tarball. I could do it, if > I knew exactly which forests and tags contain the right stuff (and could > upload it somewhere on openjdk.java.net). In fact, I have something > generic already written [1]. Feel free to use it. > > > and update releases that we can't work on as part of OpenJDK (like > > 7u55), > > I am not sure I follow. If you can commit the source to the repository > and tag it, why can't you create a source bundle for those tags? > > > The added complexity provides little benefit, and the simplest way to > remove > > the complexity is to remove the issue causing it, and educate users to > use > > the source ... directly from the respective source repository. > > I respectfully disagree with your solution. If not providing source > bundles causes confusion, wouldn't the right fix be to provide source > bundles? > > As for benefit, just today I saw people asking on #openjdk about where > to get source bundles. And they complained that using source control to > get a release bundles is too hard (and shouldn't be necessary). > > Also, if you think users have problems distinguishing 7u60 from 7u55, > can you imagine the problems they will have trying to find the > real/final tag for 7u55 in the repos? And how some tags do not exist in > some repos at some points in time? [2]. > > Thanks, > Omair > > [1] > http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/generate_source_tarball.sh > [2] > http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008969.html > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Thu May 22 01:47:23 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 21 May 2014 18:47:23 -0700 Subject: openjdk build pages In-Reply-To: References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> Message-ID: Another way to look at it is that "jdk7u40" is a tag that will gather far more interest than the build-specific tags "jdk7u40-b62" currently available, which are likely mostly of interest to Oracle release engineering. On Wed, May 21, 2014 at 6:38 PM, Martin Buchholz wrote: > A slight tangent, but maybe y'all could expand the URLs that allow you to > download an entire repo to make this particular way of grabbing bundles > more convenient: > > 1. In addition to the various labels like "jdk7u40-b62" that include a > build number, when jdk7u40 is finally released, simply add a tag "jdk7u40" > that is the true final released jdk7u40. It would point to the same > revision as the last build, presumably jdk7u40-b62". This allows you to > download via URL, e.g. > > http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/archive/jdk7u40.zip > > 2. (some hg hacking required) Expand the per-repo URLs to download all > the repos with one URL, e.g. > > http://hg.openjdk.java.net/jdk7u/jdk7u/whole-tree/archive/jdk7u40.zip > > > On Wed, May 21, 2014 at 4:44 PM, Omair Majid wrote: > >> * dalibor topic [2014-05-21 05:15]: >> > Actually, I think that for 7u60 (and 7u80) we need to move in the other >> > direction, and not publish separate source bundles from the source code >> > that's already in the Project's Mercurial repositories. >> >> I encourage you to think again. The source code system used by OpenJDK >> (hg trees) is not straight-forward to work with for packagers, and needs >> non-standard tools, like the trees extension, to fetch complete and >> consistent things. >> >> Source bundles are really easy to work with as a packager. You know you >> got something consistent that works and don't have to mess around with >> source code control systems checking out various repositories and tags >> to find the 'right' source. >> >> > Beside being potentially error prone, >> >> I am not sure I understand. Surely you can write a script that grabs the >> right tags from the right forests to create a tarball. I could do it, if >> I knew exactly which forests and tags contain the right stuff (and could >> upload it somewhere on openjdk.java.net). In fact, I have something >> generic already written [1]. Feel free to use it. >> >> > and update releases that we can't work on as part of OpenJDK (like >> > 7u55), >> >> I am not sure I follow. If you can commit the source to the repository >> and tag it, why can't you create a source bundle for those tags? >> >> > The added complexity provides little benefit, and the simplest way to >> remove >> > the complexity is to remove the issue causing it, and educate users to >> use >> > the source ... directly from the respective source repository. >> >> I respectfully disagree with your solution. If not providing source >> bundles causes confusion, wouldn't the right fix be to provide source >> bundles? >> >> As for benefit, just today I saw people asking on #openjdk about where >> to get source bundles. And they complained that using source control to >> get a release bundles is too hard (and shouldn't be necessary). >> >> Also, if you think users have problems distinguishing 7u60 from 7u55, >> can you imagine the problems they will have trying to find the >> real/final tag for 7u55 in the repos? And how some tags do not exist in >> some repos at some points in time? [2]. >> >> Thanks, >> Omair >> >> [1] >> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/generate_source_tarball.sh >> [2] >> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008969.html >> -- >> PGP Key: 66484681 (http://pgp.mit.edu/) >> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu May 22 02:08:21 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 22 May 2014 12:08:21 +1000 Subject: openjdk build pages In-Reply-To: References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> Message-ID: <537D5C15.1000900@oracle.com> On 22/05/2014 11:47 AM, Martin Buchholz wrote: > Another way to look at it is that "jdk7u40" is a tag that will gather > far more interest than the build-specific tags "jdk7u40-b62" currently > available, which are likely mostly of interest to Oracle release > engineering. The problem with the build tags is that you have to know which build is the GA build beforehand - so a "GA" tag would be generally useful I think. But that would not address the issue with non-public releases, like 7u55, as there is no GA build of that release in that forest. Even if you add a tag after all the corresponding changesets are added, that wont give you 7u55, it will give you 7u plus the 7u55 changes. David ------ > > On Wed, May 21, 2014 at 6:38 PM, Martin Buchholz > wrote: > > A slight tangent, but maybe y'all could expand the URLs that allow > you to download an entire repo to make this particular way of > grabbing bundles more convenient: > > 1. In addition to the various labels like "jdk7u40-b62" that include > a build number, when jdk7u40 is finally released, simply add a tag > "jdk7u40" that is the true final released jdk7u40. It would point > to the same revision as the last build, presumably jdk7u40-b62". > This allows you to download via URL, e.g. > > http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/archive/jdk7u40.zip > > > 2. (some hg hacking required) Expand the per-repo URLs to download > all the repos with one URL, e.g. > > http://hg.openjdk.java.net/jdk7u/jdk7u/whole-tree/archive/jdk7u40.zip > > > On Wed, May 21, 2014 at 4:44 PM, Omair Majid > wrote: > > * dalibor topic > [2014-05-21 05:15]: > > Actually, I think that for 7u60 (and 7u80) we need to move in > the other > > direction, and not publish separate source bundles from the > source code > > that's already in the Project's Mercurial repositories. > > I encourage you to think again. The source code system used by > OpenJDK > (hg trees) is not straight-forward to work with for packagers, > and needs > non-standard tools, like the trees extension, to fetch complete and > consistent things. > > Source bundles are really easy to work with as a packager. You > know you > got something consistent that works and don't have to mess > around with > source code control systems checking out various repositories > and tags > to find the 'right' source. > > > Beside being potentially error prone, > > I am not sure I understand. Surely you can write a script that > grabs the > right tags from the right forests to create a tarball. I could > do it, if > I knew exactly which forests and tags contain the right stuff > (and could > upload it somewhere on openjdk.java.net > ). In fact, I have something > generic already written [1]. Feel free to use it. > > > and update releases that we can't work on as part of OpenJDK > (like > > 7u55), > > I am not sure I follow. If you can commit the source to the > repository > and tag it, why can't you create a source bundle for those tags? > > > The added complexity provides little benefit, and the > simplest way to remove > > the complexity is to remove the issue causing it, and educate > users to use > > the source ... directly from the respective source repository. > > I respectfully disagree with your solution. If not providing source > bundles causes confusion, wouldn't the right fix be to provide > source > bundles? > > As for benefit, just today I saw people asking on #openjdk about > where > to get source bundles. And they complained that using source > control to > get a release bundles is too hard (and shouldn't be necessary). > > Also, if you think users have problems distinguishing 7u60 from > 7u55, > can you imagine the problems they will have trying to find the > real/final tag for 7u55 in the repos? And how some tags do not > exist in > some repos at some points in time? [2]. > > Thanks, > Omair > > [1] > http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/generate_source_tarball.sh > [2] > http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008969.html > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > > > From martinrb at google.com Thu May 22 02:25:27 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 21 May 2014 19:25:27 -0700 Subject: openjdk build pages In-Reply-To: <537D5C15.1000900@oracle.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> <537D5C15.1000900@oracle.com> Message-ID: On Wed, May 21, 2014 at 7:08 PM, David Holmes wrote: > On 22/05/2014 11:47 AM, Martin Buchholz wrote: > >> Another way to look at it is that "jdk7u40" is a tag that will gather >> far more interest than the build-specific tags "jdk7u40-b62" currently >> available, which are likely mostly of interest to Oracle release >> engineering. >> > > The problem with the build tags is that you have to know which build is > the GA build beforehand I don't see why that would be true. You can apply a tag to any revision in the past. So whenever jdk7u40 is officially released, at that time you tag the corresponding revision. It should not matter that it's the same revision as jdk7u40-b62, and that other tag may have been created much earlier. If you make a mistake, you can recover - tags are mutable if you use -f. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu May 22 02:30:18 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 22 May 2014 12:30:18 +1000 Subject: openjdk build pages In-Reply-To: References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> <537D5C15.1000900@oracle.com> Message-ID: <537D613A.7060405@oracle.com> On 22/05/2014 12:25 PM, Martin Buchholz wrote: > > > > On Wed, May 21, 2014 at 7:08 PM, David Holmes > wrote: > > On 22/05/2014 11:47 AM, Martin Buchholz wrote: > > Another way to look at it is that "jdk7u40" is a tag that will > gather > far more interest than the build-specific tags "jdk7u40-b62" > currently > available, which are likely mostly of interest to Oracle release > engineering. > > > The problem with the build tags is that you have to know which build > is the GA build beforehand > > > I don't see why that would be true. You can apply a tag to any revision > in the past. So whenever jdk7u40 is officially released, at that time > you tag the corresponding revision. It should not matter that it's the > same revision as jdk7u40-b62, and that other tag may have been created > much earlier. If you make a mistake, you can recover - tags are mutable > if you use -f. I think you misunderstood what I meant - I was agreeing with you :) We can tell someone 'hey if you want 7u40 GA you use tag 7u40-b62' for example. But if someone just wonders "hmm how do I get GA for 7u40?" they would need to know that b62 was it. Now they might reasonably infer that by looking at all the build tags and taking the last one, but it would be simpler if there was a more obvious tag to use, like 7u40 or 7u40-GA. David From martinrb at google.com Thu May 22 02:51:18 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 21 May 2014 19:51:18 -0700 Subject: openjdk build pages In-Reply-To: <537D613A.7060405@oracle.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> <537D5C15.1000900@oracle.com> <537D613A.7060405@oracle.com> Message-ID: On Wed, May 21, 2014 at 7:30 PM, David Holmes wrote: > On 22/05/2014 12:25 PM, Martin Buchholz wrote: > >> >> >> >> On Wed, May 21, 2014 at 7:08 PM, David Holmes > > wrote: >> >> On 22/05/2014 11:47 AM, Martin Buchholz wrote: >> >> Another way to look at it is that "jdk7u40" is a tag that will >> gather >> far more interest than the build-specific tags "jdk7u40-b62" >> currently >> available, which are likely mostly of interest to Oracle release >> engineering. >> >> >> The problem with the build tags is that you have to know which build >> is the GA build beforehand >> >> >> I don't see why that would be true. You can apply a tag to any revision >> in the past. So whenever jdk7u40 is officially released, at that time >> you tag the corresponding revision. It should not matter that it's the >> same revision as jdk7u40-b62, and that other tag may have been created >> much earlier. If you make a mistake, you can recover - tags are mutable >> if you use -f. >> > > I think you misunderstood what I meant - I was agreeing with you :) Ohhh... > We can tell someone 'hey if you want 7u40 GA you use tag 7u40-b62' for > example. But if someone just wonders "hmm how do I get GA for 7u40?" they > would need to know that b62 was it. Now they might reasonably infer that by > looking at all the build tags and taking the last one, but it would be > simpler if there was a more obvious tag to use, like 7u40 or 7u40-GA. Right! -------------- next part -------------- An HTML attachment was scrubbed... URL: From linuxhippy at gmail.com Thu May 22 11:27:30 2014 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 22 May 2014 13:27:30 +0200 Subject: Planetjdk.org is down In-Reply-To: <20140519150040.867506@eggemoggin.niobe.net> References: <20140519150040.867506@eggemoggin.niobe.net> Message-ID: Hi Mark, > It's back. (One last casualty of the recent server migration ...) Thanks :) - Clemens From dalibor.topic at oracle.com Thu May 22 15:22:04 2014 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 22 May 2014 17:22:04 +0200 Subject: openjdk build pages In-Reply-To: <537D5C15.1000900@oracle.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> <537D5C15.1000900@oracle.com> Message-ID: <537E161C.90303@oracle.com> Once an update release is released, cloning its forest will give you the OpenJDK source code for the release, as the forests are sealed once a release has been published. So there is no need for an explicit GA tag, etc for such releases - just cloning without any tags will do the job. On 22.05.2014 04:08, David Holmes wrote: > On 22/05/2014 11:47 AM, Martin Buchholz wrote: >> Another way to look at it is that "jdk7u40" is a tag that will gather >> far more interest than the build-specific tags "jdk7u40-b62" currently >> available, which are likely mostly of interest to Oracle release >> engineering. > > The problem with the build tags is that you have to know which build is > the GA build beforehand - so a "GA" tag would be generally useful I think. > > But that would not address the issue with non-public releases, like > 7u55, as there is no GA build of that release in that forest. Even if > you add a tag after all the corresponding changesets are added, that > wont give you 7u55, it will give you 7u plus the 7u55 changes. > > David > ------ > >> >> On Wed, May 21, 2014 at 6:38 PM, Martin Buchholz > > wrote: >> >> A slight tangent, but maybe y'all could expand the URLs that allow >> you to download an entire repo to make this particular way of >> grabbing bundles more convenient: >> >> 1. In addition to the various labels like "jdk7u40-b62" that include >> a build number, when jdk7u40 is finally released, simply add a tag >> "jdk7u40" that is the true final released jdk7u40. It would point >> to the same revision as the last build, presumably jdk7u40-b62". >> This allows you to download via URL, e.g. >> >> http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/archive/jdk7u40.zip >> >> >> >> >> 2. (some hg hacking required) Expand the per-repo URLs to download >> all the repos with one URL, e.g. >> >> >> http://hg.openjdk.java.net/jdk7u/jdk7u/whole-tree/archive/jdk7u40.zip >> >> >> >> >> On Wed, May 21, 2014 at 4:44 PM, Omair Majid > > wrote: >> >> * dalibor topic > > [2014-05-21 05:15]: >> > Actually, I think that for 7u60 (and 7u80) we need to move in >> the other >> > direction, and not publish separate source bundles from the >> source code >> > that's already in the Project's Mercurial repositories. >> >> I encourage you to think again. The source code system used by >> OpenJDK >> (hg trees) is not straight-forward to work with for packagers, >> and needs >> non-standard tools, like the trees extension, to fetch >> complete and >> consistent things. >> >> Source bundles are really easy to work with as a packager. You >> know you >> got something consistent that works and don't have to mess >> around with >> source code control systems checking out various repositories >> and tags >> to find the 'right' source. >> >> > Beside being potentially error prone, >> >> I am not sure I understand. Surely you can write a script that >> grabs the >> right tags from the right forests to create a tarball. I could >> do it, if >> I knew exactly which forests and tags contain the right stuff >> (and could >> upload it somewhere on openjdk.java.net >> ). In fact, I have something >> generic already written [1]. Feel free to use it. >> >> > and update releases that we can't work on as part of OpenJDK >> (like >> > 7u55), >> >> I am not sure I follow. If you can commit the source to the >> repository >> and tag it, why can't you create a source bundle for those tags? >> >> > The added complexity provides little benefit, and the >> simplest way to remove >> > the complexity is to remove the issue causing it, and educate >> users to use >> > the source ... directly from the respective source repository. >> >> I respectfully disagree with your solution. If not providing >> source >> bundles causes confusion, wouldn't the right fix be to provide >> source >> bundles? >> >> As for benefit, just today I saw people asking on #openjdk about >> where >> to get source bundles. And they complained that using source >> control to >> get a release bundles is too hard (and shouldn't be necessary). >> >> Also, if you think users have problems distinguishing 7u60 from >> 7u55, >> can you imagine the problems they will have trying to find the >> real/final tag for 7u55 in the repos? And how some tags do not >> exist in >> some repos at some points in time? [2]. >> >> Thanks, >> Omair >> >> [1] >> >> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/generate_source_tarball.sh >> >> [2] >> >> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008969.html >> -- >> PGP Key: 66484681 (http://pgp.mit.edu/) >> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 >> >> >> -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From martinrb at google.com Thu May 22 15:48:01 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 22 May 2014 08:48:01 -0700 Subject: openjdk build pages In-Reply-To: <537E161C.90303@oracle.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> <537D5C15.1000900@oracle.com> <537E161C.90303@oracle.com> Message-ID: On Thu, May 22, 2014 at 8:22 AM, dalibor topic wrote: > Once an update release is released, cloning its forest will give you the > OpenJDK source code for the release, as the forests are sealed once a > release has been published. So there is no need for an explicit GA tag, etc > for such releases - just cloning without any tags will do the job. > > While you are right, this feels like more of a workaround than a reason not to create these "GA" tags. In any revision control system with labels, creating labels for actual releases is the single most natural and obvious thing to do. Also, you don't need the actual 7u40 forest. If you happen to have a jdk7u forest, you can do hg tupdate -r jdk7u40-b62 Why not allow hg tupdate -r jdk7u40 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kellyohair at gmail.com Thu May 22 16:39:36 2014 From: kellyohair at gmail.com (Kelly O'Hair) Date: Thu, 22 May 2014 09:39:36 -0700 Subject: openjdk build pages In-Reply-To: References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> <537D5C15.1000900@oracle.com> <537E161C.90303@oracle.com> Message-ID: <0734D437-29FE-4197-8702-A944652B357E@gmail.com> I agree with Martin. Always wondered why we never did this. In fact, when the jdkNuNN-bNN tag is created, just create a jdkNuNN tag at the same time, all the time. That way it would refer to the latest build of an update. It would move from update to update, then get locked down on the last one. -kto On May 22, 2014, at 8:48 AM, Martin Buchholz wrote: > > > > On Thu, May 22, 2014 at 8:22 AM, dalibor topic wrote: > Once an update release is released, cloning its forest will give you the OpenJDK source code for the release, as the forests are sealed once a release has been published. So there is no need for an explicit GA tag, etc for such releases - just cloning without any tags will do the job. > > > While you are right, this feels like more of a workaround than a reason not to create these "GA" tags. In any revision control system with labels, creating labels for actual releases is the single most natural and obvious thing to do. > > Also, you don't need the actual 7u40 forest. If you happen to have a jdk7u forest, you can do > hg tupdate -r jdk7u40-b62 > > Why not allow > hg tupdate -r jdk7u40 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dalibor.topic at oracle.com Thu May 22 17:13:39 2014 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 22 May 2014 19:13:39 +0200 Subject: openjdk build pages In-Reply-To: <20140521234454.GF3957@redhat.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> Message-ID: <537E3043.5070302@oracle.com> On 22.05.2014 01:44, Omair Majid wrote: > * dalibor topic [2014-05-21 05:15]: >> Beside being potentially error prone, > > I am not sure I understand. That was a reference to the "then we have to create it manually, which is error prone" section of your previous e-mail. >> and update releases that we can't work on as part of OpenJDK (like >> 7u55), > > I am not sure I follow. If you can commit the source to the repository > and tag it, why can't you create a source bundle for those tags? It doesn't make a lot of sense for a Project to provide source code archives for releases that are not releases actually produced by the Project. > If not providing source > bundles causes confusion, wouldn't the right fix be to provide source > bundles? See above. > As for benefit, just today I saw people asking on #openjdk about where > to get source bundles. They are linked off the front (and any other OpenJDK web site) page. > And they complained that using source control to > get a release bundles is too hard (and shouldn't be necessary). I'm not sure why one would consider hg clone http://hg.openjdk.java.net/jdk7u/jdk7u40; cd jdk7u40; bash get_source.sh to be too hard compared to wget http://www.java.net/download/openjdk/jdk7u40/promoted/b43/openjdk-7u40-fcs-src-b43-26_aug_2013.zip - it seems to be fewer characters, even. ;) Yes, it's 3 short commands instead of one short command. That doesn't appear to me as a significant difference in hardship, though. > Also, if you think users have problems distinguishing 7u60 from 7u55, > can you imagine the problems they will have trying to find the > real/final tag for 7u55 in the repos? I don't see that as problematic if it's documented. For example, the Project page for JDK 7 Updates could eventually say 'Hooray! 7u60 was released. The source code available in the jdk7u/jdk7u60 repository with the release being tagged with something-or-other. Use hg clone [snip] get_source.sh to check it out.' > And how some tags do not exist in > some repos at some points in time? [2]. As soon as you have more then one forest covering the same Project, some tags won't exist in some repo at some point in time, while they exist in another, because commits to repositories are not atomic - not at the forest level, and not at the inter-forest-synchronization level. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From omajid at redhat.com Thu May 22 17:33:23 2014 From: omajid at redhat.com (Omair Majid) Date: Thu, 22 May 2014 13:33:23 -0400 Subject: openjdk build pages In-Reply-To: <537E3043.5070302@oracle.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> <537E3043.5070302@oracle.com> Message-ID: <20140522173323.GG2825@redhat.com> * dalibor topic [2014-05-22 13:13]: > On 22.05.2014 01:44, Omair Majid wrote: > >* dalibor topic [2014-05-21 05:15]: > >>and update releases that we can't work on as part of OpenJDK (like > >>7u55), > > > >I am not sure I follow. If you can commit the source to the repository > >and tag it, why can't you create a source bundle for those tags? > > It doesn't make a lot of sense for a Project to provide source code archives > for releases that are not releases actually produced by the Project. Okay, can we please start doing those releases? I mean, I think everyone agrees that people want to use the non-vulnerable versions of OpenJDK and would much rather use, say, the 7u55 release rather than 7u40. > >As for benefit, just today I saw people asking on #openjdk about where > >to get source bundles. > > They are linked off the front (and any other OpenJDK web site) page. Didn't this thread start with the issue that there are no 8u bundles published? If they are, please ignore me. > >And they complained that using source control to > >get a release bundles is too hard (and shouldn't be necessary). > > I'm not sure why one would consider > > hg clone http://hg.openjdk.java.net/jdk7u/jdk7u40; cd jdk7u40; bash > get_source.sh > > to be too hard compared to > > wget http://www.java.net/download/openjdk/jdk7u40/promoted/b43/openjdk-7u40-fcs-src-b43-26_aug_2013.zip Because the first one doesn't work with 8u. There is no way to get the latest 8u20, for example. Doing this in 8u will get you the latest 8u in development. It wont get you the latest tag for 8u20 (or 8, for that matter). Also, get_source.sh checks out the latest sub-repos, not the one matching the parent tag. With all due respect, if you can make this mistake, how do you expect users to avoid it? > - it seems to be fewer characters, even. ;) But it's completely unusable for someone trying to get a known-good what-was-realeased-as-8u20 1 year from today. > >Also, if you think users have problems distinguishing 7u60 from 7u55, > >can you imagine the problems they will have trying to find the > >real/final tag for 7u55 in the repos? > > I don't see that as problematic if it's documented. > > For example, the Project page for JDK 7 Updates could eventually say > 'Hooray! 7u60 was released. The source code available in the jdk7u/jdk7u60 > repository with the release being tagged with something-or-other. Use hg > clone [snip] get_source.sh to check it out.' Does this mean this will be fixed? > > And how some tags do not exist in > >some repos at some points in time? [2]. > > As soon as you have more then one forest covering the same Project, some > tags won't exist in some repo at some point in time, while they exist in > another, because commits to repositories are not atomic - not at the forest > level, and not at the inter-forest-synchronization level. Exactly. It's much easier to figure out what the latest release is if you have a canonical source bundle available rather than hunting through all the various project repositories trying to find out where a tag is. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From kellyohair at gmail.com Thu May 22 23:41:39 2014 From: kellyohair at gmail.com (Kelly O'Hair) Date: Thu, 22 May 2014 16:41:39 -0700 Subject: openjdk build pages In-Reply-To: <537D5C15.1000900@oracle.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> <537D5C15.1000900@oracle.com> Message-ID: Don't use GA, just always redefine the jdk7u40 tag to refer to the latest build of that update. You can redefine the jdk7u40 tag every time you create the jdk7u40-bNNN tag. So jdk7u40 becomes "the latest", and ultimately, the "final" one. -kto On May 21, 2014, at 7:08 PM, David Holmes wrote: > On 22/05/2014 11:47 AM, Martin Buchholz wrote: >> Another way to look at it is that "jdk7u40" is a tag that will gather >> far more interest than the build-specific tags "jdk7u40-b62" currently >> available, which are likely mostly of interest to Oracle release >> engineering. > > The problem with the build tags is that you have to know which build is the GA build beforehand - so a "GA" tag would be generally useful I think. > > But that would not address the issue with non-public releases, like 7u55, as there is no GA build of that release in that forest. Even if you add a tag after all the corresponding changesets are added, that wont give you 7u55, it will give you 7u plus the 7u55 changes. > > David > ------ > >> >> On Wed, May 21, 2014 at 6:38 PM, Martin Buchholz > > wrote: >> >> A slight tangent, but maybe y'all could expand the URLs that allow >> you to download an entire repo to make this particular way of >> grabbing bundles more convenient: >> >> 1. In addition to the various labels like "jdk7u40-b62" that include >> a build number, when jdk7u40 is finally released, simply add a tag >> "jdk7u40" that is the true final released jdk7u40. It would point >> to the same revision as the last build, presumably jdk7u40-b62". >> This allows you to download via URL, e.g. >> >> http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/archive/jdk7u40.zip >> >> >> 2. (some hg hacking required) Expand the per-repo URLs to download >> all the repos with one URL, e.g. >> >> http://hg.openjdk.java.net/jdk7u/jdk7u/whole-tree/archive/jdk7u40.zip >> >> >> On Wed, May 21, 2014 at 4:44 PM, Omair Majid > > wrote: >> >> * dalibor topic > > [2014-05-21 05:15]: >> > Actually, I think that for 7u60 (and 7u80) we need to move in >> the other >> > direction, and not publish separate source bundles from the >> source code >> > that's already in the Project's Mercurial repositories. >> >> I encourage you to think again. The source code system used by >> OpenJDK >> (hg trees) is not straight-forward to work with for packagers, >> and needs >> non-standard tools, like the trees extension, to fetch complete and >> consistent things. >> >> Source bundles are really easy to work with as a packager. You >> know you >> got something consistent that works and don't have to mess >> around with >> source code control systems checking out various repositories >> and tags >> to find the 'right' source. >> >> > Beside being potentially error prone, >> >> I am not sure I understand. Surely you can write a script that >> grabs the >> right tags from the right forests to create a tarball. I could >> do it, if >> I knew exactly which forests and tags contain the right stuff >> (and could >> upload it somewhere on openjdk.java.net >> ). In fact, I have something >> generic already written [1]. Feel free to use it. >> >> > and update releases that we can't work on as part of OpenJDK >> (like >> > 7u55), >> >> I am not sure I follow. If you can commit the source to the >> repository >> and tag it, why can't you create a source bundle for those tags? >> >> > The added complexity provides little benefit, and the >> simplest way to remove >> > the complexity is to remove the issue causing it, and educate >> users to use >> > the source ... directly from the respective source repository. >> >> I respectfully disagree with your solution. If not providing source >> bundles causes confusion, wouldn't the right fix be to provide >> source >> bundles? >> >> As for benefit, just today I saw people asking on #openjdk about >> where >> to get source bundles. And they complained that using source >> control to >> get a release bundles is too hard (and shouldn't be necessary). >> >> Also, if you think users have problems distinguishing 7u60 from >> 7u55, >> can you imagine the problems they will have trying to find the >> real/final tag for 7u55 in the repos? And how some tags do not >> exist in >> some repos at some points in time? [2]. >> >> Thanks, >> Omair >> >> [1] >> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/generate_source_tarball.sh >> [2] >> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008969.html >> -- >> PGP Key: 66484681 (http://pgp.mit.edu/) >> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 >> >> >> From martinrb at google.com Fri May 23 03:18:48 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 22 May 2014 20:18:48 -0700 Subject: openjdk build pages In-Reply-To: References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> <537D5C15.1000900@oracle.com> Message-ID: On Thu, May 22, 2014 at 4:41 PM, Kelly O'Hair wrote: > Don't use GA, just always redefine the jdk7u40 tag to refer to the latest > build of that update. > You can redefine the jdk7u40 tag every time you create the jdk7u40-bNNN > tag. > > So jdk7u40 becomes "the latest", and ultimately, the "final" one. > > I would be very happy with Kelly's suggestion. Even better might be to have jdk7u40-latest-build refer to the last successful build (I think of a "build" as a micro-release), while jdk7u40 would be reserved for the "final" release, with only slightly more work for the release engineers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dalibor.topic at oracle.com Fri May 23 08:59:31 2014 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 23 May 2014 10:59:31 +0200 Subject: openjdk build pages In-Reply-To: References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> <537D5C15.1000900@oracle.com> Message-ID: <537F0DF3.9040707@oracle.com> The problem with moving tags is that what you get when you clone a repository with a tag depends on when you cloned it. On 23.05.2014 01:41, Kelly O'Hair wrote: > Don't use GA, just always redefine the jdk7u40 tag to refer to the latest build of that update. > You can redefine the jdk7u40 tag every time you create the jdk7u40-bNNN tag. > > So jdk7u40 becomes "the latest", and ultimately, the "final" one. > > -kto > > On May 21, 2014, at 7:08 PM, David Holmes wrote: > >> On 22/05/2014 11:47 AM, Martin Buchholz wrote: >>> Another way to look at it is that "jdk7u40" is a tag that will gather >>> far more interest than the build-specific tags "jdk7u40-b62" currently >>> available, which are likely mostly of interest to Oracle release >>> engineering. >> >> The problem with the build tags is that you have to know which build is the GA build beforehand - so a "GA" tag would be generally useful I think. >> >> But that would not address the issue with non-public releases, like 7u55, as there is no GA build of that release in that forest. Even if you add a tag after all the corresponding changesets are added, that wont give you 7u55, it will give you 7u plus the 7u55 changes. >> >> David >> ------ >> >>> >>> On Wed, May 21, 2014 at 6:38 PM, Martin Buchholz >> > wrote: >>> >>> A slight tangent, but maybe y'all could expand the URLs that allow >>> you to download an entire repo to make this particular way of >>> grabbing bundles more convenient: >>> >>> 1. In addition to the various labels like "jdk7u40-b62" that include >>> a build number, when jdk7u40 is finally released, simply add a tag >>> "jdk7u40" that is the true final released jdk7u40. It would point >>> to the same revision as the last build, presumably jdk7u40-b62". >>> This allows you to download via URL, e.g. >>> >>> http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/archive/jdk7u40.zip >>> >>> >>> 2. (some hg hacking required) Expand the per-repo URLs to download >>> all the repos with one URL, e.g. >>> >>> http://hg.openjdk.java.net/jdk7u/jdk7u/whole-tree/archive/jdk7u40.zip >>> >>> >>> On Wed, May 21, 2014 at 4:44 PM, Omair Majid >> > wrote: >>> >>> * dalibor topic >> > [2014-05-21 05:15]: >>> > Actually, I think that for 7u60 (and 7u80) we need to move in >>> the other >>> > direction, and not publish separate source bundles from the >>> source code >>> > that's already in the Project's Mercurial repositories. >>> >>> I encourage you to think again. The source code system used by >>> OpenJDK >>> (hg trees) is not straight-forward to work with for packagers, >>> and needs >>> non-standard tools, like the trees extension, to fetch complete and >>> consistent things. >>> >>> Source bundles are really easy to work with as a packager. You >>> know you >>> got something consistent that works and don't have to mess >>> around with >>> source code control systems checking out various repositories >>> and tags >>> to find the 'right' source. >>> >>> > Beside being potentially error prone, >>> >>> I am not sure I understand. Surely you can write a script that >>> grabs the >>> right tags from the right forests to create a tarball. I could >>> do it, if >>> I knew exactly which forests and tags contain the right stuff >>> (and could >>> upload it somewhere on openjdk.java.net >>> ). In fact, I have something >>> generic already written [1]. Feel free to use it. >>> >>> > and update releases that we can't work on as part of OpenJDK >>> (like >>> > 7u55), >>> >>> I am not sure I follow. If you can commit the source to the >>> repository >>> and tag it, why can't you create a source bundle for those tags? >>> >>> > The added complexity provides little benefit, and the >>> simplest way to remove >>> > the complexity is to remove the issue causing it, and educate >>> users to use >>> > the source ... directly from the respective source repository. >>> >>> I respectfully disagree with your solution. If not providing source >>> bundles causes confusion, wouldn't the right fix be to provide >>> source >>> bundles? >>> >>> As for benefit, just today I saw people asking on #openjdk about >>> where >>> to get source bundles. And they complained that using source >>> control to >>> get a release bundles is too hard (and shouldn't be necessary). >>> >>> Also, if you think users have problems distinguishing 7u60 from >>> 7u55, >>> can you imagine the problems they will have trying to find the >>> real/final tag for 7u55 in the repos? And how some tags do not >>> exist in >>> some repos at some points in time? [2]. >>> >>> Thanks, >>> Omair >>> >>> [1] >>> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/generate_source_tarball.sh >>> [2] >>> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008969.html >>> -- >>> PGP Key: 66484681 (http://pgp.mit.edu/) >>> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 >>> >>> >>> > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Fri May 23 10:02:57 2014 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 23 May 2014 12:02:57 +0200 Subject: openjdk build pages In-Reply-To: <20140522173323.GG2825@redhat.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> <537E3043.5070302@oracle.com> <20140522173323.GG2825@redhat.com> Message-ID: <537F1CD1.7060004@oracle.com> On 22.05.2014 19:33, Omair Majid wrote: > Okay, can we please start doing those releases? Such releases (CPU, SA) can not be developed as part of the OpenJDK JDK 7 Updates Project, so we can't just 'do' them the way we do a release like 7u40, 7u60 or 8u20. The 7u Q&A explains all that at http://openjdk.java.net/projects/jdk7u/qanda.html . For why just zipping a clone of a tagged forest and declaring that to be 'a release' is not that great an idea either for the update Projects, see http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-May/006506.html . >>> As for benefit, just today I saw people asking on #openjdk about where >>> to get source bundles. >> >> They are linked off the front (and any other OpenJDK web site) page. > > Didn't this thread start with the issue that there are no 8u bundles > published? If they are, please ignore me. 8u20 has not been released yet, so no source archive for the release have been published. See http://openjdk.java.net/projects/jdk8u/releases/8u20.html for the timeline - still some time to go, according to the plan (which, as usual, may change). >>> And they complained that using source control to >>> get a release bundles is too hard (and shouldn't be necessary). >> >> I'm not sure why one would consider >> >> hg clone http://hg.openjdk.java.net/jdk7u/jdk7u40; cd jdk7u40; bash >> get_source.sh >> >> to be too hard compared to >> >> wget http://www.java.net/download/openjdk/jdk7u40/promoted/b43/openjdk-7u40-fcs-src-b43-26_aug_2013.zip > > Because the first one doesn't work with 8u. There is no way to get the > latest 8u20, for example. Doing this in 8u will get you the latest 8u > in development. It wont get you the latest tag for 8u20 (or 8, for that > matter). We were talking about release bundles. There is no 8u20 release yet, as it is still in development, as you observed, so 'release' bundles can't really exist yet. Once the jdk8u/jdk8u20 forest is sealed after the release, it should also work as described above. > Also, get_source.sh checks out the latest sub-repos, not the one > matching the parent tag. With all due respect, if you can make this > mistake, how do you expect users to avoid it? By repeating what I wrote, I'd hope. Here's what happens when you do: [dtopic at dtopic-linux src]$ hg clone http://hg.openjdk.java.net/jdk7u/jdk7u40 destination directory: jdk7u40 requesting all changes adding changesets adding manifests adding file changes added 731 changesets with 703 changes to 34 files updating to branch default 33 files updated, 0 files merged, 0 files removed, 0 files unresolved [dtopic at dtopic-linux src]$ cd jdk7u40/ [dtopic at dtopic-linux jdk7u40]$ bash get_source.sh # Repos: corba jaxp jaxws langtools jdk hotspot Starting on corba Starting on jaxp Starting on jaxws Starting on langtools Starting on jdk Starting on hotspot # hg clone http://hg.openjdk.java.net/jdk7u/jdk7u40/corba corba requesting all changes adding changesets adding manifests adding file changes added 665 changesets with 3663 changes to 1382 files updating to branch default 1348 files updated, 0 files merged, 0 files removed, 0 files unresolved # exit code 0 # hg clone http://hg.openjdk.java.net/jdk7u/jdk7u40/langtools langtools requesting all changes adding changesets adding manifests adding file changes added 1493 changesets with 13551 changes to 4798 files updating to branch default 4458 files updated, 0 files merged, 0 files removed, 0 files unresolved # exit code 0 # hg clone http://hg.openjdk.java.net/jdk7u/jdk7u40/jaxp jaxp requesting all changes adding changesets adding manifests adding file changes added 641 changesets with 5021 changes to 4092 files updating to branch default 2073 files updated, 0 files merged, 0 files removed, 0 files unresolved # exit code 0 # hg clone http://hg.openjdk.java.net/jdk7u/jdk7u40/jaxws jaxws requesting all changes adding changesets adding manifests adding file changes added 576 changesets with 9686 changes to 5885 files updating to branch default 2898 files updated, 0 files merged, 0 files removed, 0 files unresolved # exit code 0 # hg clone http://hg.openjdk.java.net/jdk7u/jdk7u40/hotspot hotspot requesting all changes adding changesets adding manifests adding file changes added 4733 changesets with 27879 changes to 4646 files updating to branch default 4239 files updated, 0 files merged, 0 files removed, 0 files unresolved # exit code 0 # hg clone http://hg.openjdk.java.net/jdk7u/jdk7u40/jdk jdk requesting all changes adding changesets adding manifests adding file changes added 6507 changesets with 64435 changes to 21841 files updating to branch default 20565 files updated, 0 files merged, 0 files removed, 0 files unresolved # exit code 0 # Repos: ./corba . ./hotspot ./jaxp ./jaxws ./jdk ./langtools Starting on ./corba Starting on . Starting on ./hotspot Starting on ./jaxp Starting on ./jaxws Starting on ./jdk Starting on ./langtools # cd . && hg pull -u pulling from http://hg.openjdk.java.net/jdk7u/jdk7u40 searching for changes no changes found # exit code 0 # cd ./corba && hg pull -u pulling from http://hg.openjdk.java.net/jdk7u/jdk7u40/corba searching for changes no changes found # exit code 0 # cd ./jaxws && hg pull -u pulling from http://hg.openjdk.java.net/jdk7u/jdk7u40/jaxws searching for changes no changes found # exit code 0 # cd ./hotspot && hg pull -u pulling from http://hg.openjdk.java.net/jdk7u/jdk7u40/hotspot searching for changes no changes found # exit code 0 # cd ./jdk && hg pull -u pulling from http://hg.openjdk.java.net/jdk7u/jdk7u40/jdk searching for changes no changes found # exit code 0 # cd ./langtools && hg pull -u pulling from http://hg.openjdk.java.net/jdk7u/jdk7u40/langtools searching for changes no changes found # exit code 0 # cd ./jaxp && hg pull -u pulling from http://hg.openjdk.java.net/jdk7u/jdk7u40/jaxp searching for changes no changes found # exit code 0 Ok, something got cloned and checked out. So, big question ... did get_source.sh get the right sources for 7u40? [dtopic at dtopic-linux jdk7u40]$ for i in corba hotspot jaxp jaxws jdk langtools ; do echo "In repo " $i ; hg -R $i tags | head ; done In repo corba tip 664:504acad33722 jdk7u40-b60 663:08737d863a7a jdk7u40-b43 662:e29ea0b297e5 jdk7u40-b42 661:b4a480a039bc jdk7u40-b41 660:acb0571052b8 jdk7u40-b40 659:a91b57bf60bd jdk7u40-b39 658:d7c73fd53c84 jdk7u40-b38 657:8391dff270bb jdk7u40-b37 656:dc9a63376b39 jdk7u40-b36 655:cd3871b15169 In repo hotspot tip 4732:bf3a8b634b75 jdk7u40-b60 4731:af1fc2868a2b jdk7u40-b43 4730:eceae0478243 hs24-b56 4729:b8d8caf6df74 jdk7u40-b42 4724:4e779305ed58 jdk7u40-b41 4723:4445f65c4793 jdk7u40-b40 4722:86673506aeb6 jdk7u40-b39 4721:74de360e3415 jdk7u40-b38 4720:1f3b0ff9649c jdk7u40-b37 4719:295528bfcdd1 In repo jaxp tip 640:c500d4ec41ff jdk7u40-b60 639:91bc45348512 jdk7u40-b43 638:c0bd71414ea5 jdk7u40-b42 637:66363323f14d jdk7u40-b41 636:7255fb6c9060 jdk7u40-b40 635:6ea57bdf6030 jdk7u40-b39 634:322af0a5cdce jdk7u40-b38 631:680bf140cdd5 jdk7u40-b37 630:f40f45bd95d4 jdk7u40-b36 629:07024f18376c In repo jaxws tip 575:4ee34d2cf2d8 jdk7u40-b60 574:cbeef786ce48 jdk7u40-b43 573:3ee85b3793de jdk7u40-b42 572:89f6c9663d75 jdk7u40-b41 571:adc234666397 jdk7u40-b40 570:cd6971747e7a jdk7u40-b39 569:4af46770372d jdk7u40-b38 568:7ae2e9ed2c44 jdk7u40-b37 567:918e6c87b006 jdk7u40-b36 566:b75c19a170c7 In repo jdk tip 6506:168bd87376ea jdk7u40-b60 6505:ed444a09a5fd jdk7u40-b43 6504:fb25cdef17e9 jdk7u40-b42 6503:b479996d5c92 jdk7u40-b41 6502:ae85cfff71e9 jdk7u40-b40 6501:42b57fb81c39 jdk7u40-b39 6500:33921df593ed jdk7u40-b38 6497:070b277e1b43 jdk7u40-b37 6494:04036faa7fc4 jdk7u40-b36 6490:cd7a4d0b218f In repo langtools tip 1492:b2e29b79e54e jdk7u40-b60 1491:a67dbf96bf86 jdk7u40-b43 1490:988ece7b6865 jdk7u40-b42 1489:765bea9bfcfc jdk7u40-b41 1488:95cefc18bea4 jdk7u40-b40 1487:0e83f513af68 jdk7u40-b39 1486:81925e555c94 jdk7u40-b38 1485:21672c0e6691 jdk7u40-b37 1484:31908290e4c2 jdk7u40-b36 1483:6837776bcdfa Seems so. Because the jdk7u/jdk7u40 forests were sealed after the release, there are no later commits in the repositories. >> - it seems to be fewer characters, even. ;) > > But it's completely unusable for someone trying to get a known-good > what-was-realeased-as-8u20 1 year from today. I just did it for 7u40 by cloning its release forest. Granted, it wasn't released exactly a year ago, but I think it shows that cloning the release forest produces the desired results even after a certain amount of time has passed. >> For example, the Project page for JDK 7 Updates could eventually say >> 'Hooray! 7u60 was released. The source code available in the jdk7u/jdk7u60 >> repository with the release being tagged with something-or-other. Use hg >> clone [snip] get_source.sh to check it out.' > > Does this mean this will be fixed? 7u60 hasn't been released yet, so there shouldn't be anything to fix about documenting the final build's tag so far. Once 7u60 is released, I agree that the Project page should say something like that. > Exactly. It's much easier to figure out what the latest release is if > you have a canonical source bundle available rather than hunting > through all the various project repositories trying to find out where a > tag is. Sure, but you don't have to do that. You can either clone the release forest (no tags necessary in that case) once a release is done, or, in the future, look up the tags for a release on the update Project's page. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From kellyohair at gmail.com Fri May 23 16:07:36 2014 From: kellyohair at gmail.com (Kelly O'Hair) Date: Fri, 23 May 2014 09:07:36 -0700 Subject: openjdk build pages In-Reply-To: <537F0DF3.9040707@oracle.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> <537D5C15.1000900@oracle.com> <537F0DF3.9040707@oracle.com> Message-ID: <730C1832-C687-4173-8589-B89225D913E5@gmail.com> On May 23, 2014, at 1:59 AM, dalibor topic wrote: > The problem with moving tags is that what you get when you clone a repository with a tag depends on when you cloned it. That's always true when you request a clone without a tag, you never know what you will get. With a jdk7u40 tag, if it was released, it's stable, but if it isn't you get the latest jdk7u40, which should be a stable release. I don't see a problem with that. -kto > > On 23.05.2014 01:41, Kelly O'Hair wrote: >> Don't use GA, just always redefine the jdk7u40 tag to refer to the latest build of that update. >> You can redefine the jdk7u40 tag every time you create the jdk7u40-bNNN tag. >> >> So jdk7u40 becomes "the latest", and ultimately, the "final" one. >> >> -kto >> >> On May 21, 2014, at 7:08 PM, David Holmes wrote: >> >>> On 22/05/2014 11:47 AM, Martin Buchholz wrote: >>>> Another way to look at it is that "jdk7u40" is a tag that will gather >>>> far more interest than the build-specific tags "jdk7u40-b62" currently >>>> available, which are likely mostly of interest to Oracle release >>>> engineering. >>> >>> The problem with the build tags is that you have to know which build is the GA build beforehand - so a "GA" tag would be generally useful I think. >>> >>> But that would not address the issue with non-public releases, like 7u55, as there is no GA build of that release in that forest. Even if you add a tag after all the corresponding changesets are added, that wont give you 7u55, it will give you 7u plus the 7u55 changes. >>> >>> David >>> ------ >>> >>>> >>>> On Wed, May 21, 2014 at 6:38 PM, Martin Buchholz >>> > wrote: >>>> >>>> A slight tangent, but maybe y'all could expand the URLs that allow >>>> you to download an entire repo to make this particular way of >>>> grabbing bundles more convenient: >>>> >>>> 1. In addition to the various labels like "jdk7u40-b62" that include >>>> a build number, when jdk7u40 is finally released, simply add a tag >>>> "jdk7u40" that is the true final released jdk7u40. It would point >>>> to the same revision as the last build, presumably jdk7u40-b62". >>>> This allows you to download via URL, e.g. >>>> >>>> http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/archive/jdk7u40.zip >>>> >>>> >>>> 2. (some hg hacking required) Expand the per-repo URLs to download >>>> all the repos with one URL, e.g. >>>> >>>> http://hg.openjdk.java.net/jdk7u/jdk7u/whole-tree/archive/jdk7u40.zip >>>> >>>> >>>> On Wed, May 21, 2014 at 4:44 PM, Omair Majid >>> > wrote: >>>> >>>> * dalibor topic >>> > [2014-05-21 05:15]: >>>> > Actually, I think that for 7u60 (and 7u80) we need to move in >>>> the other >>>> > direction, and not publish separate source bundles from the >>>> source code >>>> > that's already in the Project's Mercurial repositories. >>>> >>>> I encourage you to think again. The source code system used by >>>> OpenJDK >>>> (hg trees) is not straight-forward to work with for packagers, >>>> and needs >>>> non-standard tools, like the trees extension, to fetch complete and >>>> consistent things. >>>> >>>> Source bundles are really easy to work with as a packager. You >>>> know you >>>> got something consistent that works and don't have to mess >>>> around with >>>> source code control systems checking out various repositories >>>> and tags >>>> to find the 'right' source. >>>> >>>> > Beside being potentially error prone, >>>> >>>> I am not sure I understand. Surely you can write a script that >>>> grabs the >>>> right tags from the right forests to create a tarball. I could >>>> do it, if >>>> I knew exactly which forests and tags contain the right stuff >>>> (and could >>>> upload it somewhere on openjdk.java.net >>>> ). In fact, I have something >>>> generic already written [1]. Feel free to use it. >>>> >>>> > and update releases that we can't work on as part of OpenJDK >>>> (like >>>> > 7u55), >>>> >>>> I am not sure I follow. If you can commit the source to the >>>> repository >>>> and tag it, why can't you create a source bundle for those tags? >>>> >>>> > The added complexity provides little benefit, and the >>>> simplest way to remove >>>> > the complexity is to remove the issue causing it, and educate >>>> users to use >>>> > the source ... directly from the respective source repository. >>>> >>>> I respectfully disagree with your solution. If not providing source >>>> bundles causes confusion, wouldn't the right fix be to provide >>>> source >>>> bundles? >>>> >>>> As for benefit, just today I saw people asking on #openjdk about >>>> where >>>> to get source bundles. And they complained that using source >>>> control to >>>> get a release bundles is too hard (and shouldn't be necessary). >>>> >>>> Also, if you think users have problems distinguishing 7u60 from >>>> 7u55, >>>> can you imagine the problems they will have trying to find the >>>> real/final tag for 7u55 in the repos? And how some tags do not >>>> exist in >>>> some repos at some points in time? [2]. >>>> >>>> Thanks, >>>> Omair >>>> >>>> [1] >>>> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/generate_source_tarball.sh >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008969.html >>>> -- >>>> PGP Key: 66484681 (http://pgp.mit.edu/) >>>> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 >>>> >>>> >>>> >> > > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > Gesch?ftsf?hrer: J?rgen Kunz > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment From martinrb at google.com Fri May 23 20:55:11 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 23 May 2014 13:55:11 -0700 Subject: openjdk build pages In-Reply-To: <730C1832-C687-4173-8589-B89225D913E5@gmail.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> <537D5C15.1000900@oracle.com> <537F0DF3.9040707@oracle.com> <730C1832-C687-4173-8589-B89225D913E5@gmail.com> Message-ID: On Fri, May 23, 2014 at 9:07 AM, Kelly O'Hair wrote: > > On May 23, 2014, at 1:59 AM, dalibor topic wrote: > > > The problem with moving tags is that what you get when you clone a > repository with a tag depends on when you cloned it. > > That's always true when you request a clone without a tag, you never know > what you will get. > > With a jdk7u40 tag, if it was released, it's stable, but if it isn't you > get the latest jdk7u40, which should be a stable release. > I don't see a problem with that. > To amplify Kelly's point, there are already (pseudo-)tags that move over time, e.g. "tip" and the endearingly named "qtip" -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Coomes at oracle.com Fri May 23 22:11:46 2014 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 23 May 2014 15:11:46 -0700 Subject: openjdk build pages In-Reply-To: <730C1832-C687-4173-8589-B89225D913E5@gmail.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> <537D5C15.1000900@oracle.com> <537F0DF3.9040707@oracle.com> <730C1832-C687-4173-8589-B89225D913E5@gmail.com> Message-ID: <21375.51106.640809.75194@mykonos.us.oracle.com> Kelly O'Hair (kellyohair at gmail.com) wrote: > > On May 23, 2014, at 1:59 AM, dalibor topic wrote: > > > The problem with moving tags is that what you get when you clone a repository with a tag depends on when you cloned it. > > That's always true when you request a clone without a tag, you never know what you will get. > > With a jdk7u40 tag, if it was released, it's stable, but if it isn't you get the latest jdk7u40, which should be a stable release. > I don't see a problem with that. I would prefer to save the release name itself (e.g., "jdk7u40") for a branch name, not a tag. It's true we don't currently use named branches, but I (and others) would like to move to model where each release lives in a separate branch, instead of in a separate repo. Note that I'm not against adding tags for the "latest build". Just don't use the unadorned release name for it. Maybe "jdk7u40-latest" for the tag? -John > > On 23.05.2014 01:41, Kelly O'Hair wrote: > >> Don't use GA, just always redefine the jdk7u40 tag to refer to the latest build of that update. > >> You can redefine the jdk7u40 tag every time you create the jdk7u40-bNNN tag. > >> > >> So jdk7u40 becomes "the latest", and ultimately, the "final" one. > >> > >> -kto > >> > >> On May 21, 2014, at 7:08 PM, David Holmes wrote: > >> > >>> On 22/05/2014 11:47 AM, Martin Buchholz wrote: > >>>> Another way to look at it is that "jdk7u40" is a tag that will gather > >>>> far more interest than the build-specific tags "jdk7u40-b62" currently > >>>> available, which are likely mostly of interest to Oracle release > >>>> engineering. > >>> > >>> The problem with the build tags is that you have to know which build is the GA build beforehand - so a "GA" tag would be generally useful I think. > >>> > >>> But that would not address the issue with non-public releases, like 7u55, as there is no GA build of that release in that forest. Even if you add a tag after all the corresponding changesets are added, that wont give you 7u55, it will give you 7u plus the 7u55 changes. > >>> > >>> David > >>> ------ > >>> > >>>> > >>>> On Wed, May 21, 2014 at 6:38 PM, Martin Buchholz >>>> > wrote: > >>>> > >>>> A slight tangent, but maybe y'all could expand the URLs that allow > >>>> you to download an entire repo to make this particular way of > >>>> grabbing bundles more convenient: > >>>> > >>>> 1. In addition to the various labels like "jdk7u40-b62" that include > >>>> a build number, when jdk7u40 is finally released, simply add a tag > >>>> "jdk7u40" that is the true final released jdk7u40. It would point > >>>> to the same revision as the last build, presumably jdk7u40-b62". > >>>> This allows you to download via URL, e.g. > >>>> > >>>> http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/archive/jdk7u40.zip > >>>> > >>>> > >>>> 2. (some hg hacking required) Expand the per-repo URLs to download > >>>> all the repos with one URL, e.g. > >>>> > >>>> http://hg.openjdk.java.net/jdk7u/jdk7u/whole-tree/archive/jdk7u40.zip > >>>> > >>>> > >>>> On Wed, May 21, 2014 at 4:44 PM, Omair Majid >>>> > wrote: > >>>> > >>>> * dalibor topic >>>> > [2014-05-21 05:15]: > >>>> > Actually, I think that for 7u60 (and 7u80) we need to move in > >>>> the other > >>>> > direction, and not publish separate source bundles from the > >>>> source code > >>>> > that's already in the Project's Mercurial repositories. > >>>> > >>>> I encourage you to think again. The source code system used by > >>>> OpenJDK > >>>> (hg trees) is not straight-forward to work with for packagers, > >>>> and needs > >>>> non-standard tools, like the trees extension, to fetch complete and > >>>> consistent things. > >>>> > >>>> Source bundles are really easy to work with as a packager. You > >>>> know you > >>>> got something consistent that works and don't have to mess > >>>> around with > >>>> source code control systems checking out various repositories > >>>> and tags > >>>> to find the 'right' source. > >>>> > >>>> > Beside being potentially error prone, > >>>> > >>>> I am not sure I understand. Surely you can write a script that > >>>> grabs the > >>>> right tags from the right forests to create a tarball. I could > >>>> do it, if > >>>> I knew exactly which forests and tags contain the right stuff > >>>> (and could > >>>> upload it somewhere on openjdk.java.net > >>>> ). In fact, I have something > >>>> generic already written [1]. Feel free to use it. > >>>> > >>>> > and update releases that we can't work on as part of OpenJDK > >>>> (like > >>>> > 7u55), > >>>> > >>>> I am not sure I follow. If you can commit the source to the > >>>> repository > >>>> and tag it, why can't you create a source bundle for those tags? > >>>> > >>>> > The added complexity provides little benefit, and the > >>>> simplest way to remove > >>>> > the complexity is to remove the issue causing it, and educate > >>>> users to use > >>>> > the source ... directly from the respective source repository. > >>>> > >>>> I respectfully disagree with your solution. If not providing source > >>>> bundles causes confusion, wouldn't the right fix be to provide > >>>> source > >>>> bundles? > >>>> > >>>> As for benefit, just today I saw people asking on #openjdk about > >>>> where > >>>> to get source bundles. And they complained that using source > >>>> control to > >>>> get a release bundles is too hard (and shouldn't be necessary). > >>>> > >>>> Also, if you think users have problems distinguishing 7u60 from > >>>> 7u55, > >>>> can you imagine the problems they will have trying to find the > >>>> real/final tag for 7u55 in the repos? And how some tags do not > >>>> exist in > >>>> some repos at some points in time? [2]. > >>>> > >>>> Thanks, > >>>> Omair > >>>> > >>>> [1] > >>>> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/generate_source_tarball.sh > >>>> [2] > >>>> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008969.html > >>>> -- > >>>> PGP Key: 66484681 (http://pgp.mit.edu/) > >>>> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > >>>> > >>>> > >>>> > >> > > > > -- > > Dalibor Topic | Principal Product Manager > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > ORACLE Deutschland B.V. & Co. KG > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Gesch?ftsf?hrer: J?rgen Kunz > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > > > Oracle is committed to developing > > practices and products that help protect the environment > From kellyohair at gmail.com Fri May 23 22:17:46 2014 From: kellyohair at gmail.com (Kelly O'Hair) Date: Fri, 23 May 2014 15:17:46 -0700 Subject: openjdk build pages In-Reply-To: <21375.51106.640809.75194@mykonos.us.oracle.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> <537D5C15.1000900@oracle.com> <537F0DF3.9040707@oracle.com> <730C1832-C687-4173-8589-B89225D913E5@gmail.com> <21375.51106.640809.75194@mykonos.us.oracle.com> Message-ID: <4581CDD9-2BBA-4897-8F89-D7E07E73DCAC@gmail.com> jdk7u40-latest would be fine. -kto On May 23, 2014, at 3:11 PM, John Coomes wrote: > Kelly O'Hair (kellyohair at gmail.com) wrote: >> >> On May 23, 2014, at 1:59 AM, dalibor topic wrote: >> >>> The problem with moving tags is that what you get when you clone a repository with a tag depends on when you cloned it. >> >> That's always true when you request a clone without a tag, you never know what you will get. >> >> With a jdk7u40 tag, if it was released, it's stable, but if it isn't you get the latest jdk7u40, which should be a stable release. >> I don't see a problem with that. > > I would prefer to save the release name itself (e.g., "jdk7u40") for a > branch name, not a tag. It's true we don't currently use named > branches, but I (and others) would like to move to model where each > release lives in a separate branch, instead of in a separate repo. > > Note that I'm not against adding tags for the "latest build". Just > don't use the unadorned release name for it. Maybe "jdk7u40-latest" > for the tag? > > -John > >>> On 23.05.2014 01:41, Kelly O'Hair wrote: >>>> Don't use GA, just always redefine the jdk7u40 tag to refer to the latest build of that update. >>>> You can redefine the jdk7u40 tag every time you create the jdk7u40-bNNN tag. >>>> >>>> So jdk7u40 becomes "the latest", and ultimately, the "final" one. >>>> >>>> -kto >>>> >>>> On May 21, 2014, at 7:08 PM, David Holmes wrote: >>>> >>>>> On 22/05/2014 11:47 AM, Martin Buchholz wrote: >>>>>> Another way to look at it is that "jdk7u40" is a tag that will gather >>>>>> far more interest than the build-specific tags "jdk7u40-b62" currently >>>>>> available, which are likely mostly of interest to Oracle release >>>>>> engineering. >>>>> >>>>> The problem with the build tags is that you have to know which build is the GA build beforehand - so a "GA" tag would be generally useful I think. >>>>> >>>>> But that would not address the issue with non-public releases, like 7u55, as there is no GA build of that release in that forest. Even if you add a tag after all the corresponding changesets are added, that wont give you 7u55, it will give you 7u plus the 7u55 changes. >>>>> >>>>> David >>>>> ------ >>>>> >>>>>> >>>>>> On Wed, May 21, 2014 at 6:38 PM, Martin Buchholz >>>>> > wrote: >>>>>> >>>>>> A slight tangent, but maybe y'all could expand the URLs that allow >>>>>> you to download an entire repo to make this particular way of >>>>>> grabbing bundles more convenient: >>>>>> >>>>>> 1. In addition to the various labels like "jdk7u40-b62" that include >>>>>> a build number, when jdk7u40 is finally released, simply add a tag >>>>>> "jdk7u40" that is the true final released jdk7u40. It would point >>>>>> to the same revision as the last build, presumably jdk7u40-b62". >>>>>> This allows you to download via URL, e.g. >>>>>> >>>>>> http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/archive/jdk7u40.zip >>>>>> >>>>>> >>>>>> 2. (some hg hacking required) Expand the per-repo URLs to download >>>>>> all the repos with one URL, e.g. >>>>>> >>>>>> http://hg.openjdk.java.net/jdk7u/jdk7u/whole-tree/archive/jdk7u40.zip >>>>>> >>>>>> >>>>>> On Wed, May 21, 2014 at 4:44 PM, Omair Majid >>>>> > wrote: >>>>>> >>>>>> * dalibor topic >>>>> > [2014-05-21 05:15]: >>>>>>> Actually, I think that for 7u60 (and 7u80) we need to move in >>>>>> the other >>>>>>> direction, and not publish separate source bundles from the >>>>>> source code >>>>>>> that's already in the Project's Mercurial repositories. >>>>>> >>>>>> I encourage you to think again. The source code system used by >>>>>> OpenJDK >>>>>> (hg trees) is not straight-forward to work with for packagers, >>>>>> and needs >>>>>> non-standard tools, like the trees extension, to fetch complete and >>>>>> consistent things. >>>>>> >>>>>> Source bundles are really easy to work with as a packager. You >>>>>> know you >>>>>> got something consistent that works and don't have to mess >>>>>> around with >>>>>> source code control systems checking out various repositories >>>>>> and tags >>>>>> to find the 'right' source. >>>>>> >>>>>>> Beside being potentially error prone, >>>>>> >>>>>> I am not sure I understand. Surely you can write a script that >>>>>> grabs the >>>>>> right tags from the right forests to create a tarball. I could >>>>>> do it, if >>>>>> I knew exactly which forests and tags contain the right stuff >>>>>> (and could >>>>>> upload it somewhere on openjdk.java.net >>>>>> ). In fact, I have something >>>>>> generic already written [1]. Feel free to use it. >>>>>> >>>>>>> and update releases that we can't work on as part of OpenJDK >>>>>> (like >>>>>>> 7u55), >>>>>> >>>>>> I am not sure I follow. If you can commit the source to the >>>>>> repository >>>>>> and tag it, why can't you create a source bundle for those tags? >>>>>> >>>>>>> The added complexity provides little benefit, and the >>>>>> simplest way to remove >>>>>>> the complexity is to remove the issue causing it, and educate >>>>>> users to use >>>>>>> the source ... directly from the respective source repository. >>>>>> >>>>>> I respectfully disagree with your solution. If not providing source >>>>>> bundles causes confusion, wouldn't the right fix be to provide >>>>>> source >>>>>> bundles? >>>>>> >>>>>> As for benefit, just today I saw people asking on #openjdk about >>>>>> where >>>>>> to get source bundles. And they complained that using source >>>>>> control to >>>>>> get a release bundles is too hard (and shouldn't be necessary). >>>>>> >>>>>> Also, if you think users have problems distinguishing 7u60 from >>>>>> 7u55, >>>>>> can you imagine the problems they will have trying to find the >>>>>> real/final tag for 7u55 in the repos? And how some tags do not >>>>>> exist in >>>>>> some repos at some points in time? [2]. >>>>>> >>>>>> Thanks, >>>>>> Omair >>>>>> >>>>>> [1] >>>>>> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/generate_source_tarball.sh >>>>>> [2] >>>>>> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008969.html >>>>>> -- >>>>>> PGP Key: 66484681 (http://pgp.mit.edu/) >>>>>> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 >>>>>> >>>>>> >>>>>> >>>> >>> >>> -- >>> Dalibor Topic | Principal Product Manager >>> Phone: +494089091214 | Mobile: +491737185961 >>> >>> >>> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg >>> >>> ORACLE Deutschland B.V. & Co. KG >>> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >>> Registergericht: Amtsgericht M?nchen, HRA 95603 >>> Gesch?ftsf?hrer: J?rgen Kunz >>> >>> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >>> Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher >>> >>> Oracle is committed to developing >>> practices and products that help protect the environment >> From david.katleman at oracle.com Fri May 23 22:20:13 2014 From: david.katleman at oracle.com (David Katleman) Date: Fri, 23 May 2014 15:20:13 -0700 Subject: tagging Re: openjdk build pages In-Reply-To: References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> <537D5C15.1000900@oracle.com> <537F0DF3.9040707@oracle.com> <730C1832-C687-4173-8589-B89225D913E5@gmail.com> Message-ID: <537FC99D.6030908@oracle.com> Slight rename/fork, since Martin & Kelly's suggestion a bit off topic of the original thread. On 5/23/2014 1:55 PM, Martin Buchholz wrote: > > On Fri, May 23, 2014 at 9:07 AM, Kelly O'Hair > wrote: > > > On May 23, 2014, at 1:59 AM, dalibor topic wrote: > > > The problem with moving tags is that what you get when you clone > a repository with a tag depends on when you cloned it. > > That's always true when you request a clone without a tag, you > never know what you will get. > > With a jdk7u40 tag, if it was released, it's stable, but if it > isn't you get the latest jdk7u40, which should be a stable release. > I don't see a problem with that. > > > To amplify Kelly's point, there are already (pseudo-)tags that move > over time, e.g. "tip" and the endearingly named "qtip" I agree that such a pseudo tag that always represents the latest of say jdk7u60 would be useful and you're right, no one knows which build is GA, until after GA actually occurs, so we could add a pair of tags jdk7u60 & jdk7u60-bXX for each promoted build. Simplifies things once jdk7u60 is released, and serves as a latest tag while 7u60 is under development. Might want to make it bit more obvious than just "jdk7u60", like "jdk7u60-current" or "jdk7u60-latest" Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From neugens.limasoftware at gmail.com Fri May 23 23:08:09 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sat, 24 May 2014 01:08:09 +0200 Subject: openjdk build pages In-Reply-To: <4581CDD9-2BBA-4897-8F89-D7E07E73DCAC@gmail.com> References: <480A6A4D-0A3E-4A48-8F3B-F346BEFE3F2A@gmail.com> <537B89DC.3070304@oracle.com> <0585B47D-7432-4960-BB16-E61848AA737A@gmail.com> <20140520182259.GE2672@redhat.com> <537C6EAE.7050006@oracle.com> <20140521234454.GF3957@redhat.com> <537D5C15.1000900@oracle.com> <537F0DF3.9040707@oracle.com> <730C1832-C687-4173-8589-B89225D913E5@gmail.com> <21375.51106.640809.75194@mykonos.us.oracle.com> <4581CDD9-2BBA-4897-8F89-D7E07E73DCAC@gmail.com> Message-ID: +1 Cheers, Mario Il 24/mag/2014 00:18 "Kelly O'Hair" ha scritto: > jdk7u40-latest would be fine. > > -kto > > On May 23, 2014, at 3:11 PM, John Coomes wrote: > > > Kelly O'Hair (kellyohair at gmail.com) wrote: > >> > >> On May 23, 2014, at 1:59 AM, dalibor topic wrote: > >> > >>> The problem with moving tags is that what you get when you clone a > repository with a tag depends on when you cloned it. > >> > >> That's always true when you request a clone without a tag, you never > know what you will get. > >> > >> With a jdk7u40 tag, if it was released, it's stable, but if it isn't > you get the latest jdk7u40, which should be a stable release. > >> I don't see a problem with that. > > > > I would prefer to save the release name itself (e.g., "jdk7u40") for a > > branch name, not a tag. It's true we don't currently use named > > branches, but I (and others) would like to move to model where each > > release lives in a separate branch, instead of in a separate repo. > > > > Note that I'm not against adding tags for the "latest build". Just > > don't use the unadorned release name for it. Maybe "jdk7u40-latest" > > for the tag? > > > > -John > > > >>> On 23.05.2014 01:41, Kelly O'Hair wrote: > >>>> Don't use GA, just always redefine the jdk7u40 tag to refer to the > latest build of that update. > >>>> You can redefine the jdk7u40 tag every time you create the > jdk7u40-bNNN tag. > >>>> > >>>> So jdk7u40 becomes "the latest", and ultimately, the "final" one. > >>>> > >>>> -kto > >>>> > >>>> On May 21, 2014, at 7:08 PM, David Holmes wrote: > >>>> > >>>>> On 22/05/2014 11:47 AM, Martin Buchholz wrote: > >>>>>> Another way to look at it is that "jdk7u40" is a tag that will > gather > >>>>>> far more interest than the build-specific tags "jdk7u40-b62" > currently > >>>>>> available, which are likely mostly of interest to Oracle release > >>>>>> engineering. > >>>>> > >>>>> The problem with the build tags is that you have to know which build > is the GA build beforehand - so a "GA" tag would be generally useful I > think. > >>>>> > >>>>> But that would not address the issue with non-public releases, like > 7u55, as there is no GA build of that release in that forest. Even if you > add a tag after all the corresponding changesets are added, that wont give > you 7u55, it will give you 7u plus the 7u55 changes. > >>>>> > >>>>> David > >>>>> ------ > >>>>> > >>>>>> > >>>>>> On Wed, May 21, 2014 at 6:38 PM, Martin Buchholz < > martinrb at google.com > >>>>>> > wrote: > >>>>>> > >>>>>> A slight tangent, but maybe y'all could expand the URLs that allow > >>>>>> you to download an entire repo to make this particular way of > >>>>>> grabbing bundles more convenient: > >>>>>> > >>>>>> 1. In addition to the various labels like "jdk7u40-b62" that > include > >>>>>> a build number, when jdk7u40 is finally released, simply add a tag > >>>>>> "jdk7u40" that is the true final released jdk7u40. It would point > >>>>>> to the same revision as the last build, presumably jdk7u40-b62". > >>>>>> This allows you to download via URL, e.g. > >>>>>> > >>>>>> > http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/archive/jdk7u40.zip > >>>>>> < > https://www.google.com/url?q=http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/archive/jdk8u5-b13.zip&usg=AFQjCNEkVB2epNK4B2YZSjcgmwvrvCqF0g > > > >>>>>> > >>>>>> 2. (some hg hacking required) Expand the per-repo URLs to > download > >>>>>> all the repos with one URL, e.g. > >>>>>> > >>>>>> > http://hg.openjdk.java.net/jdk7u/jdk7u/whole-tree/archive/jdk7u40.zip < > https://www.google.com/url?q=http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/archive/jdk8u5-b13.zip&usg=AFQjCNEkVB2epNK4B2YZSjcgmwvrvCqF0g > > > >>>>>> > >>>>>> > >>>>>> On Wed, May 21, 2014 at 4:44 PM, Omair Majid >>>>>> > wrote: > >>>>>> > >>>>>> * dalibor topic >>>>>> > [2014-05-21 05:15]: > >>>>>>> Actually, I think that for 7u60 (and 7u80) we need to move in > >>>>>> the other > >>>>>>> direction, and not publish separate source bundles from the > >>>>>> source code > >>>>>>> that's already in the Project's Mercurial repositories. > >>>>>> > >>>>>> I encourage you to think again. The source code system used by > >>>>>> OpenJDK > >>>>>> (hg trees) is not straight-forward to work with for packagers, > >>>>>> and needs > >>>>>> non-standard tools, like the trees extension, to fetch > complete and > >>>>>> consistent things. > >>>>>> > >>>>>> Source bundles are really easy to work with as a packager. You > >>>>>> know you > >>>>>> got something consistent that works and don't have to mess > >>>>>> around with > >>>>>> source code control systems checking out various repositories > >>>>>> and tags > >>>>>> to find the 'right' source. > >>>>>> > >>>>>>> Beside being potentially error prone, > >>>>>> > >>>>>> I am not sure I understand. Surely you can write a script that > >>>>>> grabs the > >>>>>> right tags from the right forests to create a tarball. I could > >>>>>> do it, if > >>>>>> I knew exactly which forests and tags contain the right stuff > >>>>>> (and could > >>>>>> upload it somewhere on openjdk.java.net > >>>>>> ). In fact, I have something > >>>>>> generic already written [1]. Feel free to use it. > >>>>>> > >>>>>>> and update releases that we can't work on as part of OpenJDK > >>>>>> (like > >>>>>>> 7u55), > >>>>>> > >>>>>> I am not sure I follow. If you can commit the source to the > >>>>>> repository > >>>>>> and tag it, why can't you create a source bundle for those > tags? > >>>>>> > >>>>>>> The added complexity provides little benefit, and the > >>>>>> simplest way to remove > >>>>>>> the complexity is to remove the issue causing it, and educate > >>>>>> users to use > >>>>>>> the source ... directly from the respective source repository. > >>>>>> > >>>>>> I respectfully disagree with your solution. If not providing > source > >>>>>> bundles causes confusion, wouldn't the right fix be to provide > >>>>>> source > >>>>>> bundles? > >>>>>> > >>>>>> As for benefit, just today I saw people asking on #openjdk > about > >>>>>> where > >>>>>> to get source bundles. And they complained that using source > >>>>>> control to > >>>>>> get a release bundles is too hard (and shouldn't be > necessary). > >>>>>> > >>>>>> Also, if you think users have problems distinguishing 7u60 > from > >>>>>> 7u55, > >>>>>> can you imagine the problems they will have trying to find the > >>>>>> real/final tag for 7u55 in the repos? And how some tags do not > >>>>>> exist in > >>>>>> some repos at some points in time? [2]. > >>>>>> > >>>>>> Thanks, > >>>>>> Omair > >>>>>> > >>>>>> [1] > >>>>>> > http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/generate_source_tarball.sh > >>>>>> [2] > >>>>>> > http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008969.html > >>>>>> -- > >>>>>> PGP Key: 66484681 (http://pgp.mit.edu/) > >>>>>> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 > 4681 > >>>>>> > >>>>>> > >>>>>> > >>>> > >>> > >>> -- > >>> Dalibor Topic | Principal Product Manager > >>> Phone: +494089091214 | Mobile: +491737185961 > >>> > >>> > >>> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > >>> > >>> ORACLE Deutschland B.V. & Co. KG > >>> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > >>> Registergericht: Amtsgericht M?nchen, HRA 95603 > >>> Gesch?ftsf?hrer: J?rgen Kunz > >>> > >>> Komplement?rin: ORACLE Deutschland Verwaltung B.V. > >>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > >>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > >>> Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > >>> > >>> Oracle is committed to developing > >>> practices and products that help protect the environment > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: