From mark at klomp.org Wed Jun 1 13:41:22 2011 From: mark at klomp.org (Mark Wielaard) Date: Wed, 01 Jun 2011 15:41:22 +0200 Subject: Project proposal: JDK 8 In-Reply-To: <20110523165202.16FD911E2@eggemoggin.niobe.net> References: <20110523165202.16FD911E2@eggemoggin.niobe.net> Message-ID: <1306935682.6421.24.camel@springer.wildebeest.org> Hi Mark, On Mon, 2011-05-23 at 09:52 -0700, mark.reinhold at oracle.com wrote: > Per the interim governance guidelines for Projects [1] I hereby propose > the creation of a new Project, JDK 8. The primary goal of this Project > will be to produce an open-source reference implementation of the Java > SE 8 Platform, to be defined by JSR 337 [2]. > > [1] http://openjdk.java.net/projects > [2] http://www.jcp.org/en/jsr/detail?id=337 Heay, this is really good news. I was so disappointed that JSR 336 didn't have an open source reference implementation [1]. It is great to see the intention of actually creating one for Java SE 8 now. But note that the current JSR 337 legal notice (section 2.18) still says the reference implementation will be under the same horribly community unfriendly terms as JSR 336. Seeing you are actually that spec lead, please update that section to proudly proclaim this time the reference implementation will actually be under the GPL! Thanks, Mark [1] http://gnu.wildebeest.org/blog/mjw/2010/11/28/moving-java-forward-through-the-jcp/ From dalibor.topic at oracle.com Wed Jun 1 14:28:54 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 01 Jun 2011 16:28:54 +0200 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: <4DE4EBC9.2000206@redhat.com> References: <20110525165220.D008A2DC4@eggemoggin.niobe.net> <4DE4ACD6.9080909@redhat.com> <4DE4E7E6.7000308@oracle.com> <4DE4EBC9.2000206@redhat.com> Message-ID: <4DE64CA6.5080605@oracle.com> On 5/31/11 3:23 PM, Andrew Haley wrote: > If you funnel all bug reports through an internal closed group, you > will have a scaling problem, and there will be a bottleneck between > bug reporters and bug fixers. Thanks for the good explanation. My next question would be wherefrom to source such a crowd that scales? cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From aph at redhat.com Wed Jun 1 14:43:43 2011 From: aph at redhat.com (Andrew Haley) Date: Wed, 01 Jun 2011 15:43:43 +0100 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: <4DE64CA6.5080605@oracle.com> References: <20110525165220.D008A2DC4@eggemoggin.niobe.net> <4DE4ACD6.9080909@redhat.com> <4DE4E7E6.7000308@oracle.com> <4DE4EBC9.2000206@redhat.com> <4DE64CA6.5080605@oracle.com> Message-ID: <4DE6501F.1050004@redhat.com> On 06/01/2011 03:28 PM, Dalibor Topic wrote: > On 5/31/11 3:23 PM, Andrew Haley wrote: >> If you funnel all bug reports through an internal closed group, you >> will have a scaling problem, and there will be a bottleneck between >> bug reporters and bug fixers. > > Thanks for the good explanation. My next question would be wherefrom > to source such a crowd that scales? The set of OpenJDK contributors would be a start. Andrew. From geir at pobox.com Wed Jun 1 14:43:32 2011 From: geir at pobox.com (Geir Magnusson Jr.) Date: Wed, 1 Jun 2011 10:43:32 -0400 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: <4DE64CA6.5080605@oracle.com> References: <20110525165220.D008A2DC4@eggemoggin.niobe.net> <4DE4ACD6.9080909@redhat.com> <4DE4E7E6.7000308@oracle.com> <4DE4EBC9.2000206@redhat.com> <4DE64CA6.5080605@oracle.com> Message-ID: isn't there a larger community of committers? On Jun 1, 2011, at 10:28 AM, Dalibor Topic wrote: > On 5/31/11 3:23 PM, Andrew Haley wrote: >> If you funnel all bug reports through an internal closed group, you >> will have a scaling problem, and there will be a bottleneck between >> bug reporters and bug fixers. > > Thanks for the good explanation. My next question would be wherefrom > to source such a crowd that scales? > > cheers, > dalibor topic > > -- > Oracle > Dalibor Topic | Java F/OSS Ambassador > Phone: +494023646738 | Mobile: +491772664192 > Oracle Java Platform Group > > ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven > > Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Wed Jun 1 16:03:46 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 01 Jun 2011 18:03:46 +0200 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: <4DE6501F.1050004@redhat.com> References: <20110525165220.D008A2DC4@eggemoggin.niobe.net> <4DE4ACD6.9080909@redhat.com> <4DE4E7E6.7000308@oracle.com> <4DE4EBC9.2000206@redhat.com> <4DE64CA6.5080605@oracle.com> <4DE6501F.1050004@redhat.com> Message-ID: <4DE662E2.4080504@oracle.com> On 6/1/11 4:43 PM, Andrew Haley wrote: > On 06/01/2011 03:28 PM, Dalibor Topic wrote: >> On 5/31/11 3:23 PM, Andrew Haley wrote: >>> If you funnel all bug reports through an internal closed group, you >>> will have a scaling problem, and there will be a bottleneck between >>> bug reporters and bug fixers. >> >> Thanks for the good explanation. My next question would be wherefrom >> to source such a crowd that scales? > > The set of OpenJDK contributors would be a start. > That's a good idea, but the thread so far wasn't very conclusive on contributors embracing such a task, unless I have misread it. Note that I'm not saying it's not worth doing, but I'd like to read something more than 'build it and they'll come' to understand why a crowd sourced from contributors would scale at that task. Numbers showing how well that works (or doesn't) with the IcedTea bug tracker and those from downstream distributions for OpenJDK packages could be an interesting data point, for example. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From aph at redhat.com Wed Jun 1 16:28:33 2011 From: aph at redhat.com (Andrew Haley) Date: Wed, 01 Jun 2011 17:28:33 +0100 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: <4DE662E2.4080504@oracle.com> References: <20110525165220.D008A2DC4@eggemoggin.niobe.net> <4DE4ACD6.9080909@redhat.com> <4DE4E7E6.7000308@oracle.com> <4DE4EBC9.2000206@redhat.com> <4DE64CA6.5080605@oracle.com> <4DE6501F.1050004@redhat.com> <4DE662E2.4080504@oracle.com> Message-ID: <4DE668B1.2030009@redhat.com> On 06/01/2011 05:03 PM, Dalibor Topic wrote: > On 6/1/11 4:43 PM, Andrew Haley wrote: >> On 06/01/2011 03:28 PM, Dalibor Topic wrote: >>> On 5/31/11 3:23 PM, Andrew Haley wrote: >>>> If you funnel all bug reports through an internal closed group, you >>>> will have a scaling problem, and there will be a bottleneck between >>>> bug reporters and bug fixers. >>> >>> Thanks for the good explanation. My next question would be wherefrom >>> to source such a crowd that scales? >> >> The set of OpenJDK contributors would be a start. >> > > That's a good idea, but the thread so far wasn't very conclusive on > contributors embracing such a task, unless I have misread it. > > Note that I'm not saying it's not worth doing, but I'd like to read > something more than 'build it and they'll come' to understand why a > crowd sourced from contributors would scale at that task. Surely it's better than only the Oracle team. How could it be worse? Andrew. From geir at pobox.com Wed Jun 1 18:40:43 2011 From: geir at pobox.com (Geir Magnusson Jr.) Date: Wed, 1 Jun 2011 14:40:43 -0400 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: <4DE668B1.2030009@redhat.com> References: <20110525165220.D008A2DC4@eggemoggin.niobe.net> <4DE4ACD6.9080909@redhat.com> <4DE4E7E6.7000308@oracle.com> <4DE4EBC9.2000206@redhat.com> <4DE64CA6.5080605@oracle.com> <4DE6501F.1050004@redhat.com> <4DE662E2.4080504@oracle.com> <4DE668B1.2030009@redhat.com> Message-ID: On Jun 1, 2011, at 12:28 PM, Andrew Haley wrote: > On 06/01/2011 05:03 PM, Dalibor Topic wrote: >> On 6/1/11 4:43 PM, Andrew Haley wrote: >>> On 06/01/2011 03:28 PM, Dalibor Topic wrote: >>>> On 5/31/11 3:23 PM, Andrew Haley wrote: >>>>> If you funnel all bug reports through an internal closed group, you >>>>> will have a scaling problem, and there will be a bottleneck between >>>>> bug reporters and bug fixers. >>>> >>>> Thanks for the good explanation. My next question would be wherefrom >>>> to source such a crowd that scales? >>> >>> The set of OpenJDK contributors would be a start. >>> >> >> That's a good idea, but the thread so far wasn't very conclusive on >> contributors embracing such a task, unless I have misread it. >> >> Note that I'm not saying it's not worth doing, but I'd like to read >> something more than 'build it and they'll come' to understand why a >> crowd sourced from contributors would scale at that task. > > Surely it's better than only the Oracle team. How could it be worse? Aren't the contributors "the team" anyway? geir From mark.reinhold at oracle.com Wed Jun 1 21:40:01 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 01 Jun 2011 14:40:01 -0700 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: aph@redhat.com; Tue, 31 May 2011 09:54:46 BST; <4DE4ACD6.9080909@redhat.com> Message-ID: <20110601214001.6FBC01212@eggemoggin.niobe.net> 2011/5/31 1:54 -0700, aph at redhat.com: > On 25/05/11 17:52, mark.reinhold at oracle.com wrote: >> ... The primary users of this bug system are OpenJDK >> Contributors. It will be readable by anyone, of course, but I'm not >> sure it should be writable by anyone other than Contributors. >> >> Oracle's intent, by the way, is to continue funding an internal team >> to triage bug reports submitted by developers and users [1]. > > But that doesn't scale. We really want a way of crowdsourcing all > of the bug-processing, and this is an important part of it. Surely > it would not be the case that all bug reports disappear into a private > queue viewable only by your internal team? That isn't going to work. Yes, I see what you mean. I agree it would be better to allow people who don't work for Oracle to join in the fun of filtering incoming bug reports. - Mark From mark.reinhold at oracle.com Wed Jun 1 21:46:51 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 01 Jun 2011 14:46:51 -0700 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: david.holmes@oracle.com; Tue, 31 May 2011 09:22:19 +1000; <4DE426AB.5060904@oracle.com> Message-ID: <20110601214651.C43781212@eggemoggin.niobe.net> 2011/5/30 16:22 -0700, david.holmes at oracle.com: > ... > > I think there is some confusion between Group roles and Project Roles here > (perhaps they have changed between the interim rules and the new proposed > bylaws). Groups don't have repositories and Group members don't have commit > rights. The basic proposed hierarchy in the draft-bylaws in terms of code > submission and review is: > > - OpenJDK Participant > - OpenJDK Contributor > - Project Author (must be a Contributor) > - Project Committer > - Project Reviewer > > then in addition we have plain old users. Right. > So my initial categorization would be: > > - Anyone should be able to submit an "incident report". > - Contributors should be able to submit "bug reports". Add, per Andrew Haley's suggestion: - Contributors should be able to update existing "incident reports" so that they can help triage incoming incidents, converting them to bugs or closing them as appropriate > - Contributors should be able to have read access to the code review system > (they can always report an issue via email). (I'd actually give everyone read access, insofar as the system can handle the load.) > - Project Authors and above should have write access to the code review system. > > Whether "incident reports" and "bug reports" go into two different systems > depends on how well the systems can handle the distinction both in terms of > easy access/use for incidents, and isolation of incidents from bugs. With the above modification, I think this is a sensible approach. To what extent can the candidate systems support the separate handling of untriaged incidents vs. accepted bugs? We should also allow non-Contributors to add information to existing incidents and bugs, and to vote on them, but (probably) not make any other kinds of updates. - Mark From roger.calnan at oracle.com Wed Jun 1 22:41:46 2011 From: roger.calnan at oracle.com (Roger Calnan) Date: Wed, 1 Jun 2011 15:41:46 -0700 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: <20110601214001.6FBC01212@eggemoggin.niobe.net> References: <20110601214001.6FBC01212@eggemoggin.niobe.net> Message-ID: <4D08CF42-4862-40E2-A76D-2958E19B884D@oracle.com> >> Surely it would not be the case that all bug reports disappear into a private >> queue viewable only by your internal team? today the bugs aren't in a private queue, all issues appear on bugs.sun.com within a day, for example: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7033945 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7022357 are incidents which haven't been picked up as bugs yet. This was done about a year ago to address the sense that incidents went into a black hole if they were not reviewed in a timely manner. To be clear the current model isn't ideal as the infrastructure on which it is based doesn't provide the filtering necessary so that it would be easy for developers to see a unified view, the goal is to have that as part of the new system. There were some early ideas sent out in April which go into more details: http://cr.openjdk.java.net/~rlewis/BugTracking/JDK%2bDefect%2bTracking.html looking at it today there are some terms that would need to be clarified when it comes to "Open JDK developer", which was raised earlier on the thread. Also I'm assuming that the rules around if bugs should be triaged should depend on the project, some may well not want any, Roger From philip.race at oracle.com Wed Jun 1 23:10:27 2011 From: philip.race at oracle.com (Phil Race) Date: Wed, 01 Jun 2011 16:10:27 -0700 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: <4D08CF42-4862-40E2-A76D-2958E19B884D@oracle.com> References: <20110601214001.6FBC01212@eggemoggin.niobe.net> <4D08CF42-4862-40E2-A76D-2958E19B884D@oracle.com> Message-ID: <4DE6C6E3.8060703@oracle.com> A lot of the volume comes from consumer type end users and one of those cited below is a good example of this : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7022357 They report bugs into our database because in large part because the hotspot error directs them there : # If you would like to submit a bug report, please visit # http://java.sun.com/webapps/bugreport/crash.jsp That does tend to result in a lot of the bugs being misfiled as hotspot bugs even though they are not related .. Also as you can see from the stack trace there, this is very likely a bug in the application which has its own DLL .. V [jvm.dll+0xfce45] C [jaclib.dll+0x7cf5] C [jaclib.dll+0x7c03] C [jagdx.dll+0x17ef] .... I'd like to think that if we continue to direct consumers there and developers to System X that the signal to noise ratio will be such that the bug database don't degenerate. Then we don't have to worry so much about restricting access. I suppose those hotspot error logs need to be updated to document the new URLs at some point. -phil. On 6/1/2011 3:41 PM, Roger Calnan wrote: >>> Surely it would not be the case that all bug reports disappear into a private >>> queue viewable only by your internal team? > today the bugs aren't in a private queue, all issues appear on bugs.sun.com > within a day, for example: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7033945 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7022357 > > are incidents which haven't been picked up as bugs yet. This was done > about a year ago to address the sense that incidents went > into a black hole if they were not reviewed in a timely manner. > > To be clear the current model isn't ideal as the infrastructure > on which it is based doesn't provide the filtering necessary so that > it would be easy for developers to see a unified view, the goal is to > have that as part of the new system. > > There were some early ideas sent out in April which go into > more details: > > http://cr.openjdk.java.net/~rlewis/BugTracking/JDK%2bDefect%2bTracking.html > > looking at it today there are some terms that would need to be > clarified when it comes to "Open JDK developer", which was > raised earlier on the thread. Also I'm assuming that the rules > around if bugs should be triaged should depend on the project, > some may well not want any, > > Roger From David.Holmes at oracle.com Thu Jun 2 01:10:54 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 02 Jun 2011 11:10:54 +1000 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: <4D08CF42-4862-40E2-A76D-2958E19B884D@oracle.com> References: <20110601214001.6FBC01212@eggemoggin.niobe.net> <4D08CF42-4862-40E2-A76D-2958E19B884D@oracle.com> Message-ID: <4DE6E31E.4020306@oracle.com> Roger Calnan said the following on 06/02/11 08:41: > Also I'm assuming that the rules > around if bugs should be triaged should depend on the project, > some may well not want any, But the initial triage has to determine if the bug has been filed against the right project/product/component. Figuring out the exact category in which to file a bug can be extremely difficult - even for the informed! - and in some cases impossible without someone actually investigating the problem to some degree. So some initial triage is unavoidable in my view. As Phil Race mentions in his email, because hotspot intercepts fatal error handling and generates potentially useful error information, the bug is always filed against hotspot. The Hotspot team even updated the error message to be more clear that hotspot detected an error outside of the VM and that you should look at the log to see which dll/library caused the problem - yet we still get numerous incident reports filed and some even turn into bug reports! (That I swiftly close ;-) ) Cheers, David From aph at redhat.com Thu Jun 2 08:57:18 2011 From: aph at redhat.com (Andrew Haley) Date: Thu, 02 Jun 2011 09:57:18 +0100 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: References: <20110525165220.D008A2DC4@eggemoggin.niobe.net> <4DE4ACD6.9080909@redhat.com> <4DE4E7E6.7000308@oracle.com> <4DE4EBC9.2000206@redhat.com> <4DE64CA6.5080605@oracle.com> <4DE6501F.1050004@redhat.com> <4DE662E2.4080504@oracle.com> <4DE668B1.2030009@redhat.com> Message-ID: <4DE7506E.1030605@redhat.com> On 01/06/11 19:40, Geir Magnusson Jr. wrote: > > On Jun 1, 2011, at 12:28 PM, Andrew Haley wrote: > >> On 06/01/2011 05:03 PM, Dalibor Topic wrote: >>> On 6/1/11 4:43 PM, Andrew Haley wrote: >>>> On 06/01/2011 03:28 PM, Dalibor Topic wrote: >>>>> On 5/31/11 3:23 PM, Andrew Haley wrote: >>>>>> If you funnel all bug reports through an internal closed group, you >>>>>> will have a scaling problem, and there will be a bottleneck between >>>>>> bug reporters and bug fixers. >>>>> >>>>> Thanks for the good explanation. My next question would be wherefrom >>>>> to source such a crowd that scales? >>>> >>>> The set of OpenJDK contributors would be a start. >>> >>> That's a good idea, but the thread so far wasn't very conclusive on >>> contributors embracing such a task, unless I have misread it. >>> >>> Note that I'm not saying it's not worth doing, but I'd like to read >>> something more than 'build it and they'll come' to understand why a >>> crowd sourced from contributors would scale at that task. >> >> Surely it's better than only the Oracle team. How could it be worse? > > Aren't the contributors "the team" anyway? I don't know. This is the first time that anyone has used "the team" without qualification. What's the relevance of this? Andrew. From geir at pobox.com Thu Jun 2 12:05:28 2011 From: geir at pobox.com (Geir Magnusson Jr.) Date: Thu, 2 Jun 2011 08:05:28 -0400 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: <4DE7506E.1030605@redhat.com> References: <20110525165220.D008A2DC4@eggemoggin.niobe.net> <4DE4ACD6.9080909@redhat.com> <4DE4E7E6.7000308@oracle.com> <4DE4EBC9.2000206@redhat.com> <4DE64CA6.5080605@oracle.com> <4DE6501F.1050004@redhat.com> <4DE662E2.4080504@oracle.com> <4DE668B1.2030009@redhat.com> <4DE7506E.1030605@redhat.com> Message-ID: <8BC1CFE3-1668-4624-9CE1-2EEF514E3B5E@pobox.com> On Jun 2, 2011, at 4:57 AM, Andrew Haley wrote: > On 01/06/11 19:40, Geir Magnusson Jr. wrote: >> >> On Jun 1, 2011, at 12:28 PM, Andrew Haley wrote: >> >>> On 06/01/2011 05:03 PM, Dalibor Topic wrote: >>>> On 6/1/11 4:43 PM, Andrew Haley wrote: >>>>> On 06/01/2011 03:28 PM, Dalibor Topic wrote: >>>>>> On 5/31/11 3:23 PM, Andrew Haley wrote: >>>>>>> If you funnel all bug reports through an internal closed group, you >>>>>>> will have a scaling problem, and there will be a bottleneck between >>>>>>> bug reporters and bug fixers. >>>>>> >>>>>> Thanks for the good explanation. My next question would be wherefrom >>>>>> to source such a crowd that scales? >>>>> >>>>> The set of OpenJDK contributors would be a start. >>>> >>>> That's a good idea, but the thread so far wasn't very conclusive on >>>> contributors embracing such a task, unless I have misread it. >>>> >>>> Note that I'm not saying it's not worth doing, but I'd like to read >>>> something more than 'build it and they'll come' to understand why a >>>> crowd sourced from contributors would scale at that task. >>> >>> Surely it's better than only the Oracle team. How could it be worse? >> >> Aren't the contributors "the team" anyway? > > I don't know. This is the first time that anyone has used "the team" > without qualification. What's the relevance of this? Really? Relevance? I guess I was just baffled at why the full set of contributors to OpenJDK wouldn't be considered "a crowd" or "the team" or whatever term you want to use for the purpose of bug triage and management. geir > > Andrew. From aph at redhat.com Thu Jun 2 13:35:38 2011 From: aph at redhat.com (Andrew Haley) Date: Thu, 02 Jun 2011 14:35:38 +0100 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: <8BC1CFE3-1668-4624-9CE1-2EEF514E3B5E@pobox.com> References: <20110525165220.D008A2DC4@eggemoggin.niobe.net> <4DE4ACD6.9080909@redhat.com> <4DE4E7E6.7000308@oracle.com> <4DE4EBC9.2000206@redhat.com> <4DE64CA6.5080605@oracle.com> <4DE6501F.1050004@redhat.com> <4DE662E2.4080504@oracle.com> <4DE668B1.2030009@redhat.com> <4DE7506E.1030605@redhat.com> <8BC1CFE3-1668-4624-9CE1-2EEF514E3B5E@pobox.com> Message-ID: <4DE791AA.9040702@redhat.com> On 06/02/2011 01:05 PM, Geir Magnusson Jr. wrote: > > On Jun 2, 2011, at 4:57 AM, Andrew Haley wrote: > >> On 01/06/11 19:40, Geir Magnusson Jr. wrote: >>> >>> On Jun 1, 2011, at 12:28 PM, Andrew Haley wrote: >>> >>>> On 06/01/2011 05:03 PM, Dalibor Topic wrote: >>>>> On 6/1/11 4:43 PM, Andrew Haley wrote: >>>>>> On 06/01/2011 03:28 PM, Dalibor Topic wrote: >>>>>>> On 5/31/11 3:23 PM, Andrew Haley wrote: >>>>>>>> If you funnel all bug reports through an internal closed group, you >>>>>>>> will have a scaling problem, and there will be a bottleneck between >>>>>>>> bug reporters and bug fixers. >>>>>>> >>>>>>> Thanks for the good explanation. My next question would be wherefrom >>>>>>> to source such a crowd that scales? >>>>>> >>>>>> The set of OpenJDK contributors would be a start. >>>>> >>>>> That's a good idea, but the thread so far wasn't very conclusive on >>>>> contributors embracing such a task, unless I have misread it. >>>>> >>>>> Note that I'm not saying it's not worth doing, but I'd like to read >>>>> something more than 'build it and they'll come' to understand why a >>>>> crowd sourced from contributors would scale at that task. >>>> >>>> Surely it's better than only the Oracle team. How could it be worse? >>> >>> Aren't the contributors "the team" anyway? >> >> I don't know. This is the first time that anyone has used "the team" >> without qualification. What's the relevance of this? > > Really? Relevance? I guess I was just baffled at why the full set > of contributors to OpenJDK wouldn't be considered "a crowd" or "the > team" or whatever term you want to use for the purpose of bug triage > and management. I think you must have missed the earlier part of this discussion. The question is whether bug triage should be done by an Oracle-only team, as proposed, or by a wider group of contributors, as suggested by me. Andrew. From roger.calnan at oracle.com Thu Jun 2 15:13:45 2011 From: roger.calnan at oracle.com (Roger Calnan) Date: Thu, 2 Jun 2011 08:13:45 -0700 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: <4DE791AA.9040702@redhat.com> References: <20110525165220.D008A2DC4@eggemoggin.niobe.net> <4DE4ACD6.9080909@redhat.com> <4DE4E7E6.7000308@oracle.com> <4DE4EBC9.2000206@redhat.com> <4DE64CA6.5080605@oracle.com> <4DE6501F.1050004@redhat.com> <4DE662E2.4080504@oracle.com> <4DE668B1.2030009@redhat.com> <4DE7506E.1030605@redhat.com> <8BC1CFE3-1668-4624-9CE1-2EEF514E3B5E@pobox.com> <4DE791AA.9040702@redhat.com> Message-ID: <20D3A133-56EC-4D53-8856-E897529DDE10@oracle.com> Andrew, > The question is whether bug triage should be done by an Oracle-only team, > as proposed, who proposed this? Roger From kelly.ohair at oracle.com Thu Jun 2 15:56:50 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 2 Jun 2011 08:56:50 -0700 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: <20D3A133-56EC-4D53-8856-E897529DDE10@oracle.com> References: <20110525165220.D008A2DC4@eggemoggin.niobe.net> <4DE4ACD6.9080909@redhat.com> <4DE4E7E6.7000308@oracle.com> <4DE4EBC9.2000206@redhat.com> <4DE64CA6.5080605@oracle.com> <4DE6501F.1050004@redhat.com> <4DE662E2.4080504@oracle.com> <4DE668B1.2030009@redhat.com> <4DE7506E.1030605@redhat.com> <8BC1CFE3-1668-4624-9CE1-2EEF514E3B5E@pobox.com> <4DE791AA.9040702@redhat.com> <20D3A133-56EC-4D53-8856-E897529DDE10@oracle.com> Message-ID: <2166C2CC-42E5-481F-B70F-FD869B3FD0B7@oracle.com> On Jun 2, 2011, at 8:13 AM, Roger Calnan wrote: > Andrew, > >> The question is whether bug triage should be done by an Oracle-only team, >> as proposed, > > who proposed this? Yeah, who proposed this? I'm pretty sure we do NOT want an Oracle-only team doing triage. One of the primary reasons for a completely open bug system is to get away from any contribution sponsoring by Oracle employees, an obvious bottleneck. Why create a new one? -kto > > Roger From mark.reinhold at oracle.com Thu Jun 2 16:13:00 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 02 Jun 2011 09:13:00 -0700 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: kelly.ohair@oracle.com; Thu, 02 Jun 2011 08:56:50 PDT; <2166C2CC-42E5-481F-B70F-FD869B3FD0B7@oracle.com> Message-ID: <20110602161300.B4E652CDA@eggemoggin.niobe.net> 2011/6/2 8:56 -0700, kelly.ohair at oracle.com: > On Jun 2, 2011, at 8:13 AM, Roger Calnan wrote: >> Andrew Haley wrote: >>> The question is whether bug triage should be done by an Oracle-only team, >>> as proposed, >> >> who proposed this? > > Yeah, who proposed this? I'm pretty sure we do NOT want an Oracle-only > team doing triage. I mentioned this as an assumption, not a proposal, but you can blame me. I've since been talked out of it. > One of the primary reasons for a completely open bug system is to get > away from any contribution sponsoring by Oracle employees, an obvious > bottleneck. Completely agree. - Mark From tallman at inbox.ru Thu Jun 2 16:51:44 2011 From: tallman at inbox.ru (=?utf-8?Q?=D0=AE=D1=80=D0=B8=D0=B9_=D0=9C=D0=B8=D1=80=D0=BE=D0=BD=D0=B5=D0=BD=D0=BA=D0=BE?=) Date: Thu, 02 Jun 2011 20:51:44 +0400 Subject: =?utf-8?Q?Wrong_applet_signature_recognition=3F?= Message-ID: Hello. I am using bank web application, which uses java-applet for logging in and for making transaction digital signatures. I am/was especially happy it works ok with open jdk, so I should not use proprietary SUN solution. Link to login page of my bank account management application: * https://retail.payment.ru/n/Auth/LoginCert.aspx But it looks like some time (at the begiining of the year) they updated certificate of applet, and I have a problem. Applet still works ok, but OpenJDK displaying me it's untrusted. While Sun JRE shows everything ok. I make some efforts to detect the problem...and it looks like OpenJDK for some reason detects only one level of signing. I.e.: - applet are signed by Open Joint-Stock Company Promsvyazbank - Open Joint-Stock Company Promsvyazbank certificate are signed by Thawte Code Signing CA - G2 - Thawte Code Signing CA - G2 certificate are signed by thawte Primary Root CA - I have thawte Primary Root CA certificate in list of trusted sertificates (for both OpenJDK and Sun platforms) And Sun shows me two levels of signing and result is "trusted", while OpenJDK shows me only one level of signing, and result is "untrusted". Maybe my analysis is wrong somehow, I knows a little about OpenJDK signing before I begins to investigate it. Now I know little more, but, still, it's only some limited non-professional efforts to understand a problem. From roger.lewis at oracle.com Thu Jun 2 19:56:28 2011 From: roger.lewis at oracle.com (Roger Lewis) Date: Thu, 02 Jun 2011 12:56:28 -0700 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: <4DE4AF74.8000504@oracle.com> References: <20110525165220.D008A2DC4@eggemoggin.niobe.net> <8D6D59F4B2924507B4869B1F7E1ECA3F@gmail.com> <4DDF9737.2030102@oracle.com> <30118FAB-F9BE-4E2C-AC3D-90ED6A7B3B97@davidherron.com> <16C519B5-3DA8-4A74-AC85-C186E1140EE6@oracle.com> <4DE35F11.3070101@linux.vnet.ibm.com> <4DE36806.9010809@oracle.com> <6B05C399-A549-48EC-96D0-9E6CDABC11CF@oracle.com> <4DE3D671.9050104@oracle.com> <4DE4217B.20104@oracle.com> <4DE4AF74.8000504@oracle.com> Message-ID: <4DE7EAEC.3090109@oracle.com> >> I agree - but that needs to be handled by the "first tier" system (as >> is mostly done today). I don't want to be the one who has to wade >> through these issues and identify them - by the time a bug gets into >> bugster today it "should" have reasonable merit and shouldn't be a >> duplicate. > It's not clear to me that we need this filtering, at least not > initially. I can't imagine end-users seeking out the OpenJDK bug > database, unless they have a message dialog or error log that tells > them to go there. So if consumers could be directed somewhere else > then there's a good chance that most of the bugs will come from > developers that want to help by reporting a bug or maybe contributing > a fix. Sure, we'll still get some poor quality bug reports but that is > par for the course. I would suggest it would be better to see how it > goes before deciding to setup a quarantine area. Another thing is that > one would hope that an open bug database will encourage more > volunteers to help, and so there should be more eyes on these bug > reports (and so one would hope that the poor reports will be closed > quickly). Filtering at this level, to some degree, can be achieved by providing an appropriate reporting path to users being targeted. Not all submission paths suit all users. For Java SE as it is today, all bug reporting occurs on bugreport.sun.com, but the depending in the context you see this domain, the page you are directed to is intended to obtain the information that is necessary to make a useful report, and present the reporters with questions that they are likely able to answer. Also, the resulting location of those reports can vary depending on the path. - For end users, on java.com, the page they are directed to: http://bugreport.sun.com/bugreport/main.jsp - Java Developers/IT administrators/'more advanced end users', and others, who find this next link in ReadMe's, on bugs.sun.com, documentation, and elsewhere are provided with : http://bugreport.sun.com/bugreport/ Within that reporting path, the questions can vary for bug vs RFEs and in some cases vary on the 'product' the reporter selects. This path 'loosely' requires fields like 'java -version', a test case, steps to reproduce, what you expected to happen and what really happens. This results in a report that looks like this, where all of the output of those fields are 'stuffed' into a description field in BugTraq: http://bugs.sun.com/view_bug.do?bug_id=6550655 - The most commonly used reporting URL (around 450 reports a month) is presented to users when they experience a HotSpot crash: http://java.sun.com/webapps/bugreport/crash.jsp which redirects to http://bugreport.sun.com/bugreport/crash.jsp In this reporting path there is an effort made to separate out end users who have experienced a crash vs. those who are developers who have the ability to diagnose and report a full and complete 'bug report'. - For those who can access BugTraq, they are able to create bug reports that do no go into a 'triage' area and are not forced to go through the lengthy set of questions. This set of paths is not perfect by any means. Overtime, with adding and improving paths, we have seen bug quality rise significantly over the single text box that appeared on what was the original reporting page: http://java.sun.com/cgi-bin/bugreport.cgi Given the vast user base of Java being able to provide the right users with an appropriate and customizable path is essential. Anonymous reporting into a non-triage area, should not be allowed, as those paths should provide a less structured reporting process. In some cases, for some, like OpenJDK contributors, there should be only a minimum set of data necessary to create a report. > >> : >> >> I was with you right up to the last sentence. Having to register >> would dissuade some users from bothering to report non-bugs (but it >> may also dissuade them from submitting real bugs!). There needs to be >> a system where a report can easily be entered by anyone, but that >> report needs to be pre-processed before being accepted as a bug (in >> todays terms it gets submitted as an "incident", processed and if >> deemed suitable then a bug is created in bugster). > I don't know how many projects allow bug reports to be submitted > anonymously. At least with bugs.openjdk.java.net you have to login, > and same thing for other bugzillas that I've submitted bugs to. With > the legacy bugs.sun.com then you also have to fill out a form with > your details. One useful thing about requiring a submitter to login is > that there is contact address, useful if follow-up is required to > duplicate or verify a bug. Bug reporting on bugs.sun.com is somewhat anonymous...... Which has lead to many hallway discussions as to whether it should be allowed. In the end is what is there today. An email address is mandatory, that email address is only validated in that is matches a name at domain.toplevelDomain format. The thought has been that people do not want to create a new account in a system to report a bug, and we want to make the process easy enough to not scare off those who do not want to go through that step. Though having a login, in some submission paths, would be nice, it was unfortunately never implemented on bugs.sun.com. Most reporters provide valid addresses, though we do see fake email addresses, that bounce. Often, even if they have a corporate address, say name at oracle.com, they will use their personal, or a name-spam at domain.com address. -Roger From roger.calnan at oracle.com Fri Jun 3 07:23:31 2011 From: roger.calnan at oracle.com (Roger Calnan) Date: Fri, 3 Jun 2011 00:23:31 -0700 Subject: Update on bug system for OpenJDK (web-discuss) In-Reply-To: <20110602161300.B4E652CDA@eggemoggin.niobe.net> References: <20110602161300.B4E652CDA@eggemoggin.niobe.net> Message-ID: perfect, looks like that we have solved that mystery!... hopefully it is now clear that triage of developer bugs is going to continue as today, in the open. Mohan, something that has come out of this thread that needs to be thought through is we need some flexibility in how we manage/triage the bugs that are submitted by the users of JavaSE (vs. the developers) may need to vary depending on the platform/component the bugs are reported on. All, another element of "support" that needs to be part of the mix is that we (Oracle) don't just handle questions from developers who use the JRE, but also their end customers. We get *lots* of feedback from consumers/end-users off: http://java.com/en/download/help/index.xml the intention is to continue this support. How we do this has not yet been determined we will likely use the bug system that we choose for developer bugs as the DB for these issues we use now is very old. These reports however will remain private as the consumers who report issues do so with no intention of their reports being public and the level of detail one gets if very low, so one has to filter looking for patterns rather than reading every item. Some issues will end up as bugs in the main system and will need to be fixed in the JRE. Roger > 2011/6/2 8:56 -0700, kelly.ohair at oracle.com: >> On Jun 2, 2011, at 8:13 AM, Roger Calnan wrote: >>> Andrew Haley wrote: >>>> The question is whether bug triage should be done by an Oracle-only team, >>>> as proposed, >>> >>> who proposed this? >> >> Yeah, who proposed this? I'm pretty sure we do NOT want an Oracle-only >> team doing triage. > > I mentioned this as an assumption, not a proposal, but you can blame me. > I've since been talked out of it. > >> One of the primary reasons for a completely open bug system is to get >> away from any contribution sponsoring by Oracle employees, an obvious >> bottleneck. > > Completely agree. > > - Mark From mark at klomp.org Thu Jun 9 14:27:37 2011 From: mark at klomp.org (Mark Wielaard) Date: Thu, 09 Jun 2011 16:27:37 +0200 Subject: Project proposal: JDK 8 In-Reply-To: <1306935682.6421.24.camel@springer.wildebeest.org> References: <20110523165202.16FD911E2@eggemoggin.niobe.net> <1306935682.6421.24.camel@springer.wildebeest.org> Message-ID: <1307629657.14409.3.camel@springer.wildebeest.org> On Wed, 2011-06-01 at 15:41 +0200, Mark Wielaard wrote: > On Mon, 2011-05-23 at 09:52 -0700, mark.reinhold at oracle.com wrote: > > Per the interim governance guidelines for Projects [1] I hereby propose > > the creation of a new Project, JDK 8. The primary goal of this Project > > will be to produce an open-source reference implementation of the Java > > SE 8 Platform, to be defined by JSR 337 [2]. > > > > [1] http://openjdk.java.net/projects > > [2] http://www.jcp.org/en/jsr/detail?id=337 > > Heay, this is really good news. I was so disappointed that JSR 336 > didn't have an open source reference implementation [1]. It is great to > see the intention of actually creating one for Java SE 8 now. But note > that the current JSR 337 legal notice (section 2.18) still says the > reference implementation will be under the same horribly community > unfriendly terms as JSR 336. Seeing you are actually that spec lead, > please update that section to proudly proclaim this time the reference > implementation will actually be under the GPL! Do I understand correctly that I am getting my wish, not just for JDK 8, but also for JDK 7? http://blogs.oracle.com/henrik/entry/moving_to_openjdk_as_the "In line with our strategy towards a more open Java ecosystem, we are going to provide a Reference Implementation that is based entirely on the OpenJDK open source code and make it available under the GPL open source license." That is awesome! Thanks, Mark > [1] > http://gnu.wildebeest.org/blog/mjw/2010/11/28/moving-java-forward-through-the-jcp/ From neugens.limasoftware at gmail.com Thu Jun 9 17:39:06 2011 From: neugens.limasoftware at gmail.com (=?utf-8?B?bmV1Z2Vucy5saW1hc29mdHdhcmVAZ21haWwuY29t?=) Date: Thu, 09 Jun 2011 19:39:06 +0200 Subject: =?utf-8?B?UmU6IFByb2plY3QgcHJvcG9zYWw6IEpESyA4?= Message-ID: <4df1056e.04d1e30a.4c76.6f98@mx.google.com> We always complain loud with Oracle when they don't do it right but almost miss the great news when they happen! ;) Congratulation guys, this is very cool! Mario -- Sent from HTC Desire... pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ ----- Reply message ----- Da: "Mark Wielaard" Data: gio, giu 9, 2011 16:27 Oggetto: Project proposal: JDK 8 A: On Wed, 2011-06-01 at 15:41 +0200, Mark Wielaard wrote: > On Mon, 2011-05-23 at 09:52 -0700, mark.reinhold at oracle.com wrote: > > Per the interim governance guidelines for Projects [1] I hereby propose > > the creation of a new Project, JDK 8. The primary goal of this Project > > will be to produce an open-source reference implementation of the Java > > SE 8 Platform, to be defined by JSR 337 [2]. > > > > [1] http://openjdk.java.net/projects > > [2] http://www.jcp.org/en/jsr/detail?id=337 > > Heay, this is really good news. I was so disappointed that JSR 336 > didn't have an open source reference implementation [1]. It is great to > see the intention of actually creating one for Java SE 8 now. But note > that the current JSR 337 legal notice (section 2.18) still says the > reference implementation will be under the same horribly community > unfriendly terms as JSR 336. Seeing you are actually that spec lead, > please update that section to proudly proclaim this time the reference > implementation will actually be under the GPL! Do I understand correctly that I am getting my wish, not just for JDK 8, but also for JDK 7? http://blogs.oracle.com/henrik/entry/moving_to_openjdk_as_the "In line with our strategy towards a more open Java ecosystem, we are going to provide a Reference Implementation that is based entirely on the OpenJDK open source code and make it available under the GPL open source license." That is awesome! Thanks, Mark > [1] > http://gnu.wildebeest.org/blog/mjw/2010/11/28/moving-java-forward-through-the-jcp/ From john.boyer at abilitiessoft.com Sun Jun 12 17:04:13 2011 From: john.boyer at abilitiessoft.com (John J. Boyer) Date: Sun, 12 Jun 2011 12:04:13 -0500 Subject: Where is jni-md.h? Message-ID: <20110612170413.GA20221@s15261680.onlinehome-server.com> I am developing a Braille transcription application written in Java. It interfaces with a Braille transcription engine called liblouisutdml written in C. Both are to be cross-platform. When trying to compile liblouisutdml on Windows 7 with 64-bit openjdk-1.6 I get an error because jni-md.h is missing. Why isn't in the includes directory with jni.h? Where do I get it? Thanks, -- John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc. http://www.abilitiessoft.com Madison, Wisconsin USA Developing software for people with disabilities From neugens.limasoftware at gmail.com Sun Jun 12 17:34:22 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sun, 12 Jun 2011 19:34:22 +0200 Subject: Where is jni-md.h? In-Reply-To: <20110612170413.GA20221@s15261680.onlinehome-server.com> References: <20110612170413.GA20221@s15261680.onlinehome-server.com> Message-ID: <1307900064.4493.2.camel@galactica> Il giorno dom, 12/06/2011 alle 12.04 -0500, John J. Boyer ha scritto: > I am developing a Braille transcription application written in Java. It > interfaces with a Braille transcription engine called liblouisutdml > written in C. Both are to be cross-platform. When trying to compile > liblouisutdml on Windows 7 with 64-bit openjdk-1.6 I get an error > because jni-md.h is missing. Why isn't in the includes directory with > jni.h? Where do I get it? > > Thanks, Hello John, This is a platform dependent include (it contains the proper definitions of the JNICALL/IMPORT/EXPORT), you should be able to find it under the platform specific directory, for example: /include/linux/jni_md.h or /include/windows/jni_md.h Cheers, Mario From mark at klomp.org Wed Jun 15 23:37:57 2011 From: mark at klomp.org (Mark Wielaard) Date: Thu, 16 Jun 2011 01:37:57 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: <4DF931CE.1030709@oracle.com> References: <4DF931CE.1030709@oracle.com> Message-ID: <1308181077.30719.2.camel@springer.wildebeest.org> On Thu, 2011-06-16 at 00:27 +0200, Dalibor Topic wrote: > This Project will be used for developing updates to JDK 7. > > This work will be done in a separate set of repositories. Please not yet another set of repositories. You can just tag the current jdk7 repositories when you release/update. Thanks, Mark From ahughes at redhat.com Thu Jun 16 00:46:27 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 16 Jun 2011 01:46:27 +0100 Subject: Project Proposal: JDK 7 Update In-Reply-To: <1308181077.30719.2.camel@springer.wildebeest.org> References: <4DF931CE.1030709@oracle.com> <1308181077.30719.2.camel@springer.wildebeest.org> Message-ID: <20110616004627.GG9245@rivendell.middle-earth.co.uk> On 01:37 Thu 16 Jun , Mark Wielaard wrote: > On Thu, 2011-06-16 at 00:27 +0200, Dalibor Topic wrote: > > This Project will be used for developing updates to JDK 7. > > > > This work will be done in a separate set of repositories. > > Please not yet another set of repositories. You can just tag the current > jdk7 repositories when you release/update. > Yes, why does this need new repositories? Please explain. > Thanks, > > Mark > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dalibor.topic at oracle.com Thu Jun 16 10:18:09 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 16 Jun 2011 12:18:09 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: <20110616004627.GG9245@rivendell.middle-earth.co.uk> References: <4DF931CE.1030709@oracle.com> <1308181077.30719.2.camel@springer.wildebeest.org> <20110616004627.GG9245@rivendell.middle-earth.co.uk> Message-ID: <4DF9D861.8000808@oracle.com> On 6/16/11 2:46 AM, Dr Andrew John Hughes wrote: > On 01:37 Thu 16 Jun , Mark Wielaard wrote: >> On Thu, 2011-06-16 at 00:27 +0200, Dalibor Topic wrote: >>> This Project will be used for developing updates to JDK 7. >>> >>> This work will be done in a separate set of repositories. >> >> Please not yet another set of repositories. You can just tag the current >> jdk7 repositories when you release/update. >> > > Yes, why does this need new repositories? Please explain. Sure. The reason for new repos is to ensure that the materials associated with the JDK 7 Release Project remain available long-term rather than get buried under JDK 7 Update materials. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From roman at kennke.org Thu Jun 16 10:40:57 2011 From: roman at kennke.org (Roman Kennke) Date: Thu, 16 Jun 2011 12:40:57 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: <4DF9D861.8000808@oracle.com> References: <4DF931CE.1030709@oracle.com> <1308181077.30719.2.camel@springer.wildebeest.org> <20110616004627.GG9245@rivendell.middle-earth.co.uk> <4DF9D861.8000808@oracle.com> Message-ID: <1308220857.2560.4.camel@debian> > On 6/16/11 2:46 AM, Dr Andrew John Hughes wrote: > > On 01:37 Thu 16 Jun , Mark Wielaard wrote: > >> On Thu, 2011-06-16 at 00:27 +0200, Dalibor Topic wrote: > >>> This Project will be used for developing updates to JDK 7. > >>> > >>> This work will be done in a separate set of repositories. > >> > >> Please not yet another set of repositories. You can just tag the current > >> jdk7 repositories when you release/update. > >> > > > > Yes, why does this need new repositories? Please explain. > > Sure. The reason for new repos is to ensure that the materials associated > with the JDK 7 Release Project remain available long-term rather than get > buried under JDK 7 Update materials. With all respect, but this seems backwards. The point of having a VCS is to have the stuff available long term. Just do a tag, and when you need the release go back to that tag. Branching a new repository (forest) seems counterintuitive for me. The JDK7 repositories would then become a dead end, right? And the jdk7-update repos would become the new jdk7 development. Are you planning to branch off a new forest for each jdk7 update release as well? Another related thing that I was thinking about today is that the website that shows the repositories could be improved to only show the toplevel repositories of each forest and have an expand button to make the subrepos visible. This way the mess would be a little easier to look at. Best regards, Roman From spoole at linux.vnet.ibm.com Thu Jun 16 10:42:10 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Thu, 16 Jun 2011 11:42:10 +0100 Subject: Project Proposal: JDK 7 Update In-Reply-To: <4DF9D861.8000808@oracle.com> References: <4DF931CE.1030709@oracle.com> <1308181077.30719.2.camel@springer.wildebeest.org> <20110616004627.GG9245@rivendell.middle-earth.co.uk> <4DF9D861.8000808@oracle.com> Message-ID: <4DF9DE02.3070408@linux.vnet.ibm.com> On 16/06/11 11:18, Dalibor Topic wrote: > On 6/16/11 2:46 AM, Dr Andrew John Hughes wrote: >> On 01:37 Thu 16 Jun , Mark Wielaard wrote: >>> On Thu, 2011-06-16 at 00:27 +0200, Dalibor Topic wrote: >>>> This Project will be used for developing updates to JDK 7. >>>> >>>> This work will be done in a separate set of repositories. >>> Please not yet another set of repositories. You can just tag the current >>> jdk7 repositories when you release/update. >>> >> Yes, why does this need new repositories? Please explain. > Sure. The reason for new repos is to ensure that the materials associated > with the JDK 7 Release Project remain available long-term rather than get > buried under JDK 7 Update materials. > Hi Dalibor, still not sure I get this. Why can't this requirement be satisfied by using branches and/or tags? Do you intend the JDK 7 Update repos to hold all future changes for JDK7 or can we expect to see new repos when update 2,3,4 come along? > cheers, > dalibor topic From mark at klomp.org Thu Jun 16 11:20:10 2011 From: mark at klomp.org (Mark Wielaard) Date: Thu, 16 Jun 2011 13:20:10 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: <4DF9D861.8000808@oracle.com> References: <4DF931CE.1030709@oracle.com> <1308181077.30719.2.camel@springer.wildebeest.org> <20110616004627.GG9245@rivendell.middle-earth.co.uk> <4DF9D861.8000808@oracle.com> Message-ID: <1308223210.3183.3.camel@springer.wildebeest.org> On Thu, 2011-06-16 at 12:18 +0200, Dalibor Topic wrote: > On 6/16/11 2:46 AM, Dr Andrew John Hughes wrote: > > On 01:37 Thu 16 Jun , Mark Wielaard wrote: > >> On Thu, 2011-06-16 at 00:27 +0200, Dalibor Topic wrote: > >>> This Project will be used for developing updates to JDK 7. > >>> > >>> This work will be done in a separate set of repositories. > >> > >> Please not yet another set of repositories. You can just tag the current > >> jdk7 repositories when you release/update. > >> > > > > Yes, why does this need new repositories? Please explain. > > Sure. The reason for new repos is to ensure that the materials associated > with the JDK 7 Release Project remain available long-term rather than get > buried under JDK 7 Update materials. What do you mean by buried? You just have to tag the repositories with for each release/update to get exactly at the source at that time. Look at how openjdk6 handles this. There is just one jdk6 forest with each update release tagged. That is a much smoother model to follow IMHO. Otherwise one quickly cannot find the forests through the trees :) Cheers, Mark From Alan.Bateman at oracle.com Thu Jun 16 11:54:02 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Jun 2011 12:54:02 +0100 Subject: Project Proposal: JDK 7 Update In-Reply-To: <4DF9DE02.3070408@linux.vnet.ibm.com> References: <4DF931CE.1030709@oracle.com> <1308181077.30719.2.camel@springer.wildebeest.org> <20110616004627.GG9245@rivendell.middle-earth.co.uk> <4DF9D861.8000808@oracle.com> <4DF9DE02.3070408@linux.vnet.ibm.com> Message-ID: <4DF9EEDA.3080701@oracle.com> Steve Poole wrote: > > Hi Dalibor, still not sure I get this. Why can't this requirement be > satisfied by using branches and/or tags? > Do you intend the JDK 7 Update repos to hold all future changes for > JDK7 or can we expect to see new repos when update 2,3,4 come along? > I wouldn't get hung up over this. In the Q&A [1] it says that there will be "a mainline 7 repository that will always be open for putbacks". Assuming that this mainline forest starts out as a clone of jdk7/jdk7 then it will have all the history and I assume would be equivalent of just continuing jdk7/jdk7 into the future. There's isn't too much detail on how specific updates are handled. It looks like the proposal is to clone from the mainline periodically and presumably that is where the end game polka and stabilization will happen. The changes will need to get merged back into the mainline. I've no doubt HotSpot will need special handling but otherwise the overall approach looks reasonable to me. The proof will be in the eating of course and the approval process to get changes into mainline (or an integration forest that feeds into) will need to be simple and fast. -Alan. [1] http://cr.openjdk.java.net/~robilad/jdk7u/7UpdateQAndA.txt From kelly.ohair at oracle.com Thu Jun 16 15:25:40 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 16 Jun 2011 08:25:40 -0700 Subject: "JDK 7 Update" Project Message-ID: <0CCDC12C-FB1B-4759-824C-23D139617FA7@oracle.com> The OpenJDK Build Group has agreed to sponsor the "JDK 7 Update" Project [1] 5 yes votes out of 6, one person on leave. -kto [1] http://mail.openjdk.java.net/pipermail/announce/2011-June/000103.html From mark at klomp.org Thu Jun 16 17:07:59 2011 From: mark at klomp.org (Mark Wielaard) Date: Thu, 16 Jun 2011 19:07:59 +0200 (CEST) Subject: "JDK 7 Update" Project In-Reply-To: <0CCDC12C-FB1B-4759-824C-23D139617FA7@oracle.com> References: <0CCDC12C-FB1B-4759-824C-23D139617FA7@oracle.com> Message-ID: <56849.80.101.103.228.1308244079.squirrel@gnu.wildebeest.org> Hi Kelly, On Thu, June 16, 2011 17:25, Kelly O'Hair wrote: > The OpenJDK Build Group has agreed to sponsor the "JDK 7 Update" Project Although I certainly appreciate the speed and efficiently of the Build Group voting process, maybe we should first finish the discussion on the list on whether or not the updates can just be part of the regular jdk7 project tree so as to not create another set of separate trees that people will have to track. My impression is that most people would like to see that happen instead of treating the updates as yet another project. Cheers, Mark From neugens.limasoftware at gmail.com Thu Jun 16 17:20:09 2011 From: neugens.limasoftware at gmail.com (=?utf-8?B?bmV1Z2Vucy5saW1hc29mdHdhcmVAZ21haWwuY29t?=) Date: Thu, 16 Jun 2011 19:20:09 +0200 Subject: =?utf-8?B?UmU6ICJKREsgNyBVcGRhdGUiIFByb2plY3Q=?= Message-ID: <4dfa3b83.d20fd80a.6a90.6ae1@mx.google.com> +1 Mario -- Sent from HTC Desire... pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ ----- Reply message ----- Da: "Mark Wielaard" Data: gio, giu 16, 2011 19:07 Oggetto: "JDK 7 Update" Project A: "Kelly O'Hair" Cc: Hi Kelly, On Thu, June 16, 2011 17:25, Kelly O'Hair wrote: > The OpenJDK Build Group has agreed to sponsor the "JDK 7 Update" Project Although I certainly appreciate the speed and efficiently of the Build Group voting process, maybe we should first finish the discussion on the list on whether or not the updates can just be part of the regular jdk7 project tree so as to not create another set of separate trees that people will have to track. My impression is that most people would like to see that happen instead of treating the updates as yet another project. Cheers, Mark From dalibor.topic at oracle.com Thu Jun 16 18:21:29 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 16 Jun 2011 20:21:29 +0200 Subject: "JDK 7 Update" Project In-Reply-To: <0CCDC12C-FB1B-4759-824C-23D139617FA7@oracle.com> References: <0CCDC12C-FB1B-4759-824C-23D139617FA7@oracle.com> Message-ID: <4DFA49A9.7010707@oracle.com> On 6/16/11 5:25 PM, Kelly O'Hair wrote: > The OpenJDK Build Group has agreed to sponsor the "JDK 7 Update" Project [1] > > 5 yes votes out of 6, one person on leave. > > -kto > > [1] http://mail.openjdk.java.net/pipermail/announce/2011-June/000103.html Thanks, Kelly & Build Group Members! cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From kelly.ohair at oracle.com Thu Jun 16 18:50:07 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 16 Jun 2011 11:50:07 -0700 Subject: "JDK 7 Update" Project In-Reply-To: <56849.80.101.103.228.1308244079.squirrel@gnu.wildebeest.org> References: <0CCDC12C-FB1B-4759-824C-23D139617FA7@oracle.com> <56849.80.101.103.228.1308244079.squirrel@gnu.wildebeest.org> Message-ID: On Jun 16, 2011, at 10:07 AM, Mark Wielaard wrote: > Hi Kelly, > > On Thu, June 16, 2011 17:25, Kelly O'Hair wrote: >> The OpenJDK Build Group has agreed to sponsor the "JDK 7 Update" Project > > Although I certainly appreciate the speed and efficiently of the > Build Group voting process, maybe we should first finish the discussion > on the list on whether or not the updates can just be part of the > regular jdk7 project tree so as to not create another set of separate > trees that people will have to track. My impression is that most people > would like to see that happen instead of treating the updates as yet > another project. > In my opinion, regardless of how the repositories might be set up for it, the JDK 7 Update project still needs to exist. There was a desire to get this project going, and I was just trying to help it along. --- It was also my opinion that we could just use the existing jdk7/jdk7 repos for updates, but I was convinced otherwise. Having a frozen set of jdk7/jdk7 repos out there has some benefits, and yes, we will have tags to mark the state, and any update repos will be clones, with all the tags. Any naive user that does not understand tags, and does a simple clone jdk7/jdk7, will get exactly that, the original jdk7 release, not some arbitrary update. I'll gladly listen to the debate, maybe I'll change my mind again. ;^) -kto > Cheers, > > Mark > From mark at klomp.org Thu Jun 16 19:06:10 2011 From: mark at klomp.org (Mark Wielaard) Date: Thu, 16 Jun 2011 21:06:10 +0200 (CEST) Subject: "JDK 7 Update" Project In-Reply-To: References: <0CCDC12C-FB1B-4759-824C-23D139617FA7@oracle.com> <56849.80.101.103.228.1308244079.squirrel@gnu.wildebeest.org> Message-ID: <54537.80.101.103.228.1308251170.squirrel@gnu.wildebeest.org> Hi Kelly, On Thu, June 16, 2011 20:50, Kelly O'Hair wrote: > In my opinion, regardless of how the repositories might be set up for it, > the JDK 7 Update project still needs to exist. > There was a desire to get this project going, and I was just trying to > help it along. IMHO the jdk7 project is doing fine. What would the new project do differently that the jdk7 project couldn't just do as well? > It was also my opinion that we could just use the existing jdk7/jdk7 repos > for updates, but I was convinced otherwise. How were you convinced? I might have missed the actual discussion. > Having a frozen set of jdk7/jdk7 repos out there has some benefits, and > yes, we will have tags to mark the state, and any update repos will be > clones, with all the tags. > Any naive user that does not understand tags, and does a simple clone > jdk7/jdk7, will get exactly that, the original jdk7 release, not some > arbitrary update. I think people want the latest and greatest jdk7 if the are using hg. Though I am sure jdk7 1.0 will be great, there will be bugs. If people really want some specific release of jdk7 they can just download the source tar ball release and/or checkout a specific tag. If you are using/hacking on the jdk7 repository, you would want to be using the latest and greatest wouldn't you? > I'll gladly listen to the debate, maybe I'll change my mind again. ;^) Me too :) Thanks, Mark From mark.reinhold at oracle.com Thu Jun 16 20:51:46 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 16 Jun 2011 13:51:46 -0700 Subject: Project Proposal: JDK 7 Update In-Reply-To: mark@klomp.org; Thu, 16 Jun 2011 13:20:10 +0200; <1308223210.3183.3.camel@springer.wildebeest.org> Message-ID: <20110616205146.83F352267@eggemoggin.niobe.net> 2011/6/16 4:20 -0700, mark at klomp.org: > On Thu, 2011-06-16 at 12:18 +0200, Dalibor Topic wrote: >> Sure. The reason for new repos is to ensure that the materials associated >> with the JDK 7 Release Project remain available long-term rather than get >> buried under JDK 7 Update materials. > > What do you mean by buried? You just have to tag the repositories with > for each release/update to get exactly at the source at that time. Look > at how openjdk6 handles this. There is just one jdk6 forest with each > update release tagged. That is a much smoother model to follow IMHO. > Otherwise one quickly cannot find the forests through the trees :) There are other materials in the JDK 7 Project besides code. The various web pages describing schedule, features, milestones, etc., are likely to be of historical interest over the long term. If we use the existing JDK 7 Project for updates then that material would become harder to find, if not eventually lost altogether. The relevant URLs would almost certainly change. To put it another way, these are logically distinct Projects, with distinct participants, goals, and processes. Shoe-horning them into a single Project just risks confusing people. Finally, using the JDK 7 Project for updates would be inconsistent with the proposed Bylaws, which define a "JDK Release Project" as being for "new releases of Java SE Platform implementations". Update releases do not fit that definition. Aside from the issue of which Project to use, there will be multiple forests as Dalibor explains in his Q&A [1]: A mainline forest that's always open for incoming changesets, so that developers have somewhere to put their changes, and a forest for each actual update release, so that each release can be stabilized independently of the mainline. This is just the natural way to use a distributed VCS for parallel streams of development. Yes, Mercurial has branches, but they're generally not recommended by experts [2] and from what I've seen they haven't worked out all that well in practice. (If I recall correctly they were used briefly in IcedTea and then abandoned.) I honestly don't understand the aversion, expressed by some, to the creation of new forests. Disk space is cheap. What's the problem? - Mark [1] http://cr.openjdk.java.net/~robilad/jdk7u/7UpdateQAndA.txt [2] http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html#id386031 From mark at klomp.org Thu Jun 16 21:31:38 2011 From: mark at klomp.org (Mark Wielaard) Date: Thu, 16 Jun 2011 23:31:38 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: <20110616205146.83F352267@eggemoggin.niobe.net> References: <20110616205146.83F352267@eggemoggin.niobe.net> Message-ID: <1308259898.8032.28.camel@springer.wildebeest.org> On Thu, 2011-06-16 at 13:51 -0700, mark.reinhold at oracle.com wrote: > 2011/6/16 4:20 -0700, mark at klomp.org: > > What do you mean by buried? You just have to tag the repositories with > > for each release/update to get exactly at the source at that time. Look > > at how openjdk6 handles this. There is just one jdk6 forest with each > > update release tagged. That is a much smoother model to follow IMHO. > > Otherwise one quickly cannot find the forests through the trees :) > > There are other materials in the JDK 7 Project besides code. The various > web pages describing schedule, features, milestones, etc., are likely to > be of historical interest over the long term. If we use the existing JDK > 7 Project for updates then that material would become harder to find, if > not eventually lost altogether. The relevant URLs would almost certainly > change. Do you mean the pages under http://openjdk.java.net/projects/jdk7/ ? We could still keep using them and augment them with new information on what was added with each update. I don't think the URLs need to change at all. > To put it another way, these are logically distinct Projects, with > distinct participants, goals, and processes. Shoe-horning them into > a single Project just risks confusing people. I admit to be confused :) If you were talking about jdk6 vs jdk7 vs jdk8 then I would understand. But I honestly don't see the big difference in scope that would call for a whole new project and forest now if it is just about continuing jdk7[.x] development. Not calling that the jdk7 project feels confusing. > Finally, using the JDK 7 Project for updates would be inconsistent with > the proposed Bylaws, which define a "JDK Release Project" as being for > "new releases of Java SE Platform implementations". Update releases do > not fit that definition. Why not? They are just new (updates/bug fixes/enhancements) releases of the Java SE Platform implementation aren't they? > I honestly don't understand the aversion, expressed by some, to the > creation of new forests. Disk space is cheap. What's the problem? Changing names and locations is always a bit confusing. That is just it. And it is just that jdk6 is going so well and is pleasant to work with because it is just one forest with each update tagged that made me happy with that way of working. So personally I would like to see that also be used to continue jdk7 if possible. It would be shame to break up something we are used to that is all. Wouldn't it be an idea to instead of branching off for the next update, to branch off and archive jdk7 1.0 on a special release page/URL under http://openjdk.java.net/projects/jdk7/releases/1.0/ when we are satisfied it is finished, put some tar balls, the archived feature, milestones, builds and calender under it and then keep the jdk7 project as being the update project? From a developer standpoint that seems nicer to keep up with than having to change every time there is a new update just to keep on top of the latest jdk7 development. BTW. I am not dead against having a new project. If people feel that is the best thing to do to keep improving jdk7. I am just surprised because it feels much more natural to just keep using the jdk7 project to work on jdk7 stuff instead of having to go through all the trouble of setting up a new project and repositories. But I am sure you feel surprised the same way, just in reverse :) Cheers, Mark From volker.simonis at gmail.com Fri Jun 17 08:08:33 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jun 2011 10:08:33 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: <20110616205146.83F352267@eggemoggin.niobe.net> References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> Message-ID: Hi Mark (R), why so many words for so simple things? My impression is that this discussion is just not honest from the Oracle part. Your work model for JDK 6 has always been to prepare update releases in separate, closed repositories and then, after they have been released, throw them over into the OpenJDK. And probably you want to keep this model for JDK7 as well. I'm not completely sure about the 'jdk' part, but this was definitely true for the HotSpotExpress repositories. I don't want to criticise this working model at all. I understand that there are security holes which you don't want to disclose until they are actually fixed AND released (and there may be other stuff like Java for Buisness releases which you don't want to disclose as well). But for this working model it's easier to have separate trees for each update release and for me that's the single (and understandable) reason why you want to do it that way. But then I suggest to just tell the people the truth and everybody will understand it instead of just beating around the bush. Just my opinion, Volker On Thu, Jun 16, 2011 at 10:51 PM, wrote: > 2011/6/16 4:20 -0700, mark at klomp.org: >> On Thu, 2011-06-16 at 12:18 +0200, Dalibor Topic wrote: >>> Sure. The reason for new repos is to ensure that the materials associated >>> with the JDK 7 Release Project remain available long-term rather than get >>> buried under JDK 7 Update materials. >> >> What do you mean by buried? You just have to tag the repositories with >> for each release/update to get exactly at the source at that time. Look >> at how openjdk6 handles this. There is just one jdk6 forest with each >> update release tagged. That is a much smoother model to follow IMHO. >> Otherwise one quickly cannot find the forests through the trees :) > > There are other materials in the JDK 7 Project besides code. ?The various > web pages describing schedule, features, milestones, etc., are likely to > be of historical interest over the long term. ?If we use the existing JDK > 7 Project for updates then that material would become harder to find, if > not eventually lost altogether. ?The relevant URLs would almost certainly > change. > > To put it another way, these are logically distinct Projects, with > distinct participants, goals, and processes. ?Shoe-horning them into > a single Project just risks confusing people. > > Finally, using the JDK 7 Project for updates would be inconsistent with > the proposed Bylaws, which define a "JDK Release Project" as being for > "new releases of Java SE Platform implementations". ?Update releases do > not fit that definition. > > Aside from the issue of which Project to use, there will be multiple > forests as Dalibor explains in his Q&A [1]: A mainline forest that's > always open for incoming changesets, so that developers have somewhere > to put their changes, and a forest for each actual update release, so > that each release can be stabilized independently of the mainline. > > This is just the natural way to use a distributed VCS for parallel > streams of development. ?Yes, Mercurial has branches, but they're > generally not recommended by experts [2] and from what I've seen they > haven't worked out all that well in practice. ?(If I recall correctly > they were used briefly in IcedTea and then abandoned.) > > I honestly don't understand the aversion, expressed by some, to the > creation of new forests. ?Disk space is cheap. ?What's the problem? > > - Mark > > > [1] http://cr.openjdk.java.net/~robilad/jdk7u/7UpdateQAndA.txt > [2] http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html#id386031 > From georges.saab at oracle.com Fri Jun 17 09:22:57 2011 From: georges.saab at oracle.com (Georges Saab) Date: Fri, 17 Jun 2011 11:22:57 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> Message-ID: <7319166E-FB7B-4C24-90F4-EC59C2F97458@oracle.com> Hi Volker -- Actually this is the opposite. This model for SCM is a best known method employed in most professional software projects: 1. A main/head line for the next major release (JDK 8) 2. An update line for the last major version (7 update) 3. Off of which individual lines for each update release is taken (7uX) 4. If 'dot.dot' releases occur then an additional level of 2 and 3 is employed. This ensures that 1. There is always a place for fixes to go in - this avoids integration traffic jams and allows good continuous integration testing to do its job 2. Isolation is provided for release stabilization where it is possible to select which fixes come in as an update release is nearing completion. In general you want to create the release lines as late as possible (but not too late :)). Having them gives you the benefit of isolation at the cost of yet another merge for fixes. If you doubt the need for isolation at some point then there is clearly a more basic discussion that is needed :). The fact that this model is now surfaced in OpenJDK 7 shows IMHO that the intent is for this to be the place where the development is really happening rather than an intermediate rest stop for code on its way up or down stream. /GES On 17 jun 2011, at 10:08, Volker Simonis wrote: > Hi Mark (R), > > why so many words for so simple things? My impression is that this > discussion is just not honest from the Oracle part. Your work model > for JDK 6 has always been to prepare update releases in separate, > closed repositories and then, after they have been released, throw > them over into the OpenJDK. And probably you want to keep this model > for JDK7 as well. I'm not completely sure about the 'jdk' part, but > this was definitely true for the HotSpotExpress repositories. > > I don't want to criticise this working model at all. I understand that > there are security holes which you don't want to disclose until they > are actually fixed AND released (and there may be other stuff like > Java for Buisness releases which you don't want to disclose as well). > But for this working model it's easier to have separate trees for each > update release and for me that's the single (and understandable) > reason why you want to do it that way. > > But then I suggest to just tell the people the truth and everybody > will understand it instead of just beating around the bush. > > Just my opinion, > Volker > > > On Thu, Jun 16, 2011 at 10:51 PM, wrote: >> 2011/6/16 4:20 -0700, mark at klomp.org: >>> On Thu, 2011-06-16 at 12:18 +0200, Dalibor Topic wrote: >>>> Sure. The reason for new repos is to ensure that the materials associated >>>> with the JDK 7 Release Project remain available long-term rather than get >>>> buried under JDK 7 Update materials. >>> >>> What do you mean by buried? You just have to tag the repositories with >>> for each release/update to get exactly at the source at that time. Look >>> at how openjdk6 handles this. There is just one jdk6 forest with each >>> update release tagged. That is a much smoother model to follow IMHO. >>> Otherwise one quickly cannot find the forests through the trees :) >> >> There are other materials in the JDK 7 Project besides code. The various >> web pages describing schedule, features, milestones, etc., are likely to >> be of historical interest over the long term. If we use the existing JDK >> 7 Project for updates then that material would become harder to find, if >> not eventually lost altogether. The relevant URLs would almost certainly >> change. >> >> To put it another way, these are logically distinct Projects, with >> distinct participants, goals, and processes. Shoe-horning them into >> a single Project just risks confusing people. >> >> Finally, using the JDK 7 Project for updates would be inconsistent with >> the proposed Bylaws, which define a "JDK Release Project" as being for >> "new releases of Java SE Platform implementations". Update releases do >> not fit that definition. >> >> Aside from the issue of which Project to use, there will be multiple >> forests as Dalibor explains in his Q&A [1]: A mainline forest that's >> always open for incoming changesets, so that developers have somewhere >> to put their changes, and a forest for each actual update release, so >> that each release can be stabilized independently of the mainline. >> >> This is just the natural way to use a distributed VCS for parallel >> streams of development. Yes, Mercurial has branches, but they're >> generally not recommended by experts [2] and from what I've seen they >> haven't worked out all that well in practice. (If I recall correctly >> they were used briefly in IcedTea and then abandoned.) >> >> I honestly don't understand the aversion, expressed by some, to the >> creation of new forests. Disk space is cheap. What's the problem? >> >> - Mark >> >> >> [1] http://cr.openjdk.java.net/~robilad/jdk7u/7UpdateQAndA.txt >> [2] http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html#id386031 >> From volker.simonis at gmail.com Fri Jun 17 09:53:18 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jun 2011 11:53:18 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: <7319166E-FB7B-4C24-90F4-EC59C2F97458@oracle.com> References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> <7319166E-FB7B-4C24-90F4-EC59C2F97458@oracle.com> Message-ID: Hi Georges, yes, I agree with you in the basic points. I think a part of the confusion comes from the fact that you are generally working on several update releases in parallel. In that case you absolutely need different forests (or branches, code lines, you name it) so you can stabilize one code line while you still integrate new changes into the code line for the next update release. It may be not clear to the community for example that the testing you do for one update release needs several weeks and you don't want to stop the work on the next but one release for this purpose. OpenJDK6 as mentioned by Mark Wielaard followed a simpler, linear release model which could be well done with a single repository. Hopefully the development will really happen in the new repositories as you promise and they will not be used just as a place where the final results are dropped to. Regards, Volker On Fri, Jun 17, 2011 at 11:22 AM, Georges Saab wrote: > Hi Volker -- > > Actually this is the opposite. > > This model for SCM is a best known method employed in most professional software projects: > 1. A main/head line for the next major release (JDK 8) > 2. An update line for the last major version (7 update) > 3. Off of which individual lines for each update release is taken (7uX) > 4. If 'dot.dot' releases occur then an additional level of 2 and 3 is employed. > > This ensures that > 1. There is always a place for fixes to go in - this avoids integration traffic jams and allows good continuous integration testing to do its job > 2. Isolation is provided for release stabilization where it is possible to select which fixes come in as an update release is nearing completion. > > In general you want to create the release lines as late as possible (but not too late :)). ?Having them gives you the benefit of isolation at the cost of yet another merge for fixes. ?If you doubt the need for isolation at some point then there is clearly a more basic discussion that is needed :). > > The fact that this model is now surfaced in OpenJDK 7 shows IMHO that the intent is for this to be the place where the development is really happening rather than an intermediate > rest stop for code on its way up or down stream. > > ?/GES > > On 17 jun 2011, at 10:08, Volker Simonis wrote: > >> Hi Mark (R), >> >> why so many words for ?so simple things? My impression is that this >> discussion is just not honest from the Oracle part. Your work model >> for JDK 6 has always been to prepare update releases in separate, >> closed repositories and then, after they have been released, throw >> them over into the OpenJDK. And probably you want to keep this model >> for JDK7 as well. I'm not completely sure about the 'jdk' part, but >> this was definitely true for the HotSpotExpress repositories. >> >> I don't want to criticise this working model at all. I understand that >> there are security holes which you don't want to disclose until they >> are actually fixed AND released (and there may be other stuff like >> Java for Buisness releases which you don't want to disclose as well). >> But for this working model it's easier to have separate trees for each >> update release and for me that's the single (and understandable) >> reason why you want to do it that way. >> >> But then I suggest to just tell the people the truth and everybody >> will understand it instead of just beating around the bush. >> >> Just my opinion, >> Volker >> >> >> On Thu, Jun 16, 2011 at 10:51 PM, ? wrote: >>> 2011/6/16 4:20 -0700, mark at klomp.org: >>>> On Thu, 2011-06-16 at 12:18 +0200, Dalibor Topic wrote: >>>>> Sure. The reason for new repos is to ensure that the materials associated >>>>> with the JDK 7 Release Project remain available long-term rather than get >>>>> buried under JDK 7 Update materials. >>>> >>>> What do you mean by buried? You just have to tag the repositories with >>>> for each release/update to get exactly at the source at that time. Look >>>> at how openjdk6 handles this. There is just one jdk6 forest with each >>>> update release tagged. That is a much smoother model to follow IMHO. >>>> Otherwise one quickly cannot find the forests through the trees :) >>> >>> There are other materials in the JDK 7 Project besides code. ?The various >>> web pages describing schedule, features, milestones, etc., are likely to >>> be of historical interest over the long term. ?If we use the existing JDK >>> 7 Project for updates then that material would become harder to find, if >>> not eventually lost altogether. ?The relevant URLs would almost certainly >>> change. >>> >>> To put it another way, these are logically distinct Projects, with >>> distinct participants, goals, and processes. ?Shoe-horning them into >>> a single Project just risks confusing people. >>> >>> Finally, using the JDK 7 Project for updates would be inconsistent with >>> the proposed Bylaws, which define a "JDK Release Project" as being for >>> "new releases of Java SE Platform implementations". ?Update releases do >>> not fit that definition. >>> >>> Aside from the issue of which Project to use, there will be multiple >>> forests as Dalibor explains in his Q&A [1]: A mainline forest that's >>> always open for incoming changesets, so that developers have somewhere >>> to put their changes, and a forest for each actual update release, so >>> that each release can be stabilized independently of the mainline. >>> >>> This is just the natural way to use a distributed VCS for parallel >>> streams of development. ?Yes, Mercurial has branches, but they're >>> generally not recommended by experts [2] and from what I've seen they >>> haven't worked out all that well in practice. ?(If I recall correctly >>> they were used briefly in IcedTea and then abandoned.) >>> >>> I honestly don't understand the aversion, expressed by some, to the >>> creation of new forests. ?Disk space is cheap. ?What's the problem? >>> >>> - Mark >>> >>> >>> [1] http://cr.openjdk.java.net/~robilad/jdk7u/7UpdateQAndA.txt >>> [2] http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html#id386031 >>> > > From dalibor.topic at oracle.com Fri Jun 17 10:47:37 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 17 Jun 2011 12:47:37 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: <1308220857.2560.4.camel@debian> References: <4DF931CE.1030709@oracle.com> <1308181077.30719.2.camel@springer.wildebeest.org> <20110616004627.GG9245@rivendell.middle-earth.co.uk> <4DF9D861.8000808@oracle.com> <1308220857.2560.4.camel@debian> Message-ID: <4DFB30C9.6070109@oracle.com> On 6/16/11 12:40 PM, Roman Kennke wrote: > The JDK7 repositories would then become a dead end, right? Yes. > And the jdk7-update repos would become the new jdk7 development. Yes. For rationale going beyond the draft Q & A, please see Mark's post here: http://mail.openjdk.java.net/pipermail/discuss/2011-June/001932.html > Are you planning to branch off a new forest for each jdk7 update release as > well? Yes. For rationale going beyond the draft Q & A, please see Georges' post here: http://mail.openjdk.java.net/pipermail/discuss/2011-June/001935.html > Another related thing that I was thinking about today is that the > website that shows the repositories could be improved to only show the > toplevel repositories of each forest and have an expand button to make > the subrepos visible. This way the mess would be a little easier to look > at. Does hgweb support that? cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Fri Jun 17 10:51:08 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 17 Jun 2011 12:51:08 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: <1308223210.3183.3.camel@springer.wildebeest.org> References: <4DF931CE.1030709@oracle.com> <1308181077.30719.2.camel@springer.wildebeest.org> <20110616004627.GG9245@rivendell.middle-earth.co.uk> <4DF9D861.8000808@oracle.com> <1308223210.3183.3.camel@springer.wildebeest.org> Message-ID: <4DFB319C.6030008@oracle.com> On 6/16/11 1:20 PM, Mark Wielaard wrote: > Otherwise one quickly cannot find the forests through the trees :) > Nice one. ;) cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From neugens.limasoftware at gmail.com Fri Jun 17 10:55:57 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 17 Jun 2011 12:55:57 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> Message-ID: <1308308159.3266.28.camel@galactica> Il giorno ven, 17/06/2011 alle 10.08 +0200, Volker Simonis ha scritto: > Hi Mark (R), > > why so many words for so simple things? My impression is that this > discussion is just not honest from the Oracle part. Your work model > for JDK 6 has always been to prepare update releases in separate, > closed repositories and then, after they have been released, throw > them over into the OpenJDK. And probably you want to keep this model > for JDK7 as well. I'm not completely sure about the 'jdk' part, but > this was definitely true for the HotSpotExpress repositories. > > I don't want to criticise this working model at all. I understand that > there are security holes which you don't want to disclose until they > are actually fixed AND released (and there may be other stuff like > Java for Buisness releases which you don't want to disclose as well). > But for this working model it's easier to have separate trees for each > update release and for me that's the single (and understandable) > reason why you want to do it that way. > > But then I suggest to just tell the people the truth and everybody > will understand it instead of just beating around the bush. > > Just my opinion, > Volker I firstly misunderstood the way this would have been implemented, because (bad Oracle!) it wasn't communicated right in the first place I guess... But I believe you see conspiracy where there is none, after all, Oracle has all the rights (both legally and morally) to have closed source branches in my opinion, and this doesn't really impact much the open developments, especially now that it seems that the true RI will be OpenJDK and not the closed version. I understood that the model would have been a branch for each release, which host development for the next branch, which is not really very well sustainable (but once again, there is nothing inherently wrong with it either). On the other end, I now seem to understand that the reality is a branch for JDK development (jdk7u), from which you get release branches, but the main development still happens in jdk7u, so in my opinion is just lots of noise for nothing :) Btw, it doesn't really change much if you get dev branches or not, if Oracle wants to push for the closed development it can do it anyway, so I really fail to see the point of your mail. Cheers, Mario P.S. I hope things will happen in the open and I believe is correct to push for this of course, I just don't see how this mail is related, other than ask that this kind of discussion takes place in public next time before getting the results of the proposal as a matter of fact. However, in this specific case I believe there was just some misunderstanding in the communication system. From dalibor.topic at oracle.com Fri Jun 17 11:46:24 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 17 Jun 2011 13:46:24 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: <1308308159.3266.28.camel@galactica> References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> <1308308159.3266.28.camel@galactica> Message-ID: <4DFB3E90.9080907@oracle.com> On 6/17/11 12:55 PM, Mario Torre wrote: > But I believe you see conspiracy where there is none, There is no need to have a thread in which people accuse each other of conspiracy theories on this mailing list. If you must have it, please take your dispute to private mail. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Fri Jun 17 11:44:26 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 17 Jun 2011 13:44:26 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> Message-ID: <4DFB3E1A.4040701@oracle.com> On 6/17/11 10:08 AM, Volker Simonis wrote: > Hi Mark (R), > > why so many words for so simple things? My impression is that this > discussion is just not honest from the Oracle part. Hi Volker, you are welcome to present arguments for doing things one way or another, like other participants in this discussion on this mailing list have done. But you're not welcome to question the honesty of other participants in the discussion on this mailing list, regardless who their employer is. That is, to put it as simply as I can, very rude. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Fri Jun 17 11:44:26 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 17 Jun 2011 13:44:26 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> Message-ID: <4DFB3E1A.4040701@oracle.com> On 6/17/11 10:08 AM, Volker Simonis wrote: > Hi Mark (R), > > why so many words for so simple things? My impression is that this > discussion is just not honest from the Oracle part. Hi Volker, you are welcome to present arguments for doing things one way or another, like other participants in this discussion on this mailing list have done. But you're not welcome to question the honesty of other participants in the discussion on this mailing list, regardless who their employer is. That is, to put it as simply as I can, very rude. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Fri Jun 17 11:46:24 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 17 Jun 2011 13:46:24 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: <1308308159.3266.28.camel@galactica> References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> <1308308159.3266.28.camel@galactica> Message-ID: <4DFB3E90.9080907@oracle.com> On 6/17/11 12:55 PM, Mario Torre wrote: > But I believe you see conspiracy where there is none, There is no need to have a thread in which people accuse each other of conspiracy theories on this mailing list. If you must have it, please take your dispute to private mail. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From georges.saab at oracle.com Fri Jun 17 12:02:44 2011 From: georges.saab at oracle.com (Georges Saab) Date: Fri, 17 Jun 2011 14:02:44 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> <7319166E-FB7B-4C24-90F4-EC59C2F97458@oracle.com> Message-ID: <0407D9B7-8A2A-4976-A160-C0355D6A4DB3@oracle.com> Exactly, the update releases are often overlapping each other in development and testing. To make things even more fun this goes on for all JDK major version lines which have active updates occurring. And for security releases it needs to happen simultaneously across major JDK version lines where the fixes may be different, the end date committed a year in advance, varying degrees of severity and impact, all in a race with researchers who want to go public and those who want to exploit. Welcome to the sausage factory ;) On 17 jun 2011, at 11:53, Volker Simonis wrote: > Hi Georges, > > yes, I agree with you in the basic points. I think a part of the > confusion comes from the fact that you are generally working on > several update releases in parallel. In that case you absolutely need > different forests (or branches, code lines, you name it) so you can > stabilize one code line while you still integrate new changes into the > code line for the next update release. It may be not clear to the > community for example that the testing you do for one update release > needs several weeks and you don't want to stop the work on the next > but one release for this purpose. > > OpenJDK6 as mentioned by Mark Wielaard followed a simpler, linear > release model which could be well done with a single repository. > > Hopefully the development will really happen in the new repositories > as you promise and they will not be used just as a place where the > final results are dropped to. > > Regards, > Volker > > On Fri, Jun 17, 2011 at 11:22 AM, Georges Saab wrote: >> Hi Volker -- >> >> Actually this is the opposite. >> >> This model for SCM is a best known method employed in most professional software projects: >> 1. A main/head line for the next major release (JDK 8) >> 2. An update line for the last major version (7 update) >> 3. Off of which individual lines for each update release is taken (7uX) >> 4. If 'dot.dot' releases occur then an additional level of 2 and 3 is employed. >> >> This ensures that >> 1. There is always a place for fixes to go in - this avoids integration traffic jams and allows good continuous integration testing to do its job >> 2. Isolation is provided for release stabilization where it is possible to select which fixes come in as an update release is nearing completion. >> >> In general you want to create the release lines as late as possible (but not too late :)). Having them gives you the benefit of isolation at the cost of yet another merge for fixes. If you doubt the need for isolation at some point then there is clearly a more basic discussion that is needed :). >> >> The fact that this model is now surfaced in OpenJDK 7 shows IMHO that the intent is for this to be the place where the development is really happening rather than an intermediate >> rest stop for code on its way up or down stream. >> >> /GES >> >> On 17 jun 2011, at 10:08, Volker Simonis wrote: >> >>> Hi Mark (R), >>> >>> why so many words for so simple things? My impression is that this >>> discussion is just not honest from the Oracle part. Your work model >>> for JDK 6 has always been to prepare update releases in separate, >>> closed repositories and then, after they have been released, throw >>> them over into the OpenJDK. And probably you want to keep this model >>> for JDK7 as well. I'm not completely sure about the 'jdk' part, but >>> this was definitely true for the HotSpotExpress repositories. >>> >>> I don't want to criticise this working model at all. I understand that >>> there are security holes which you don't want to disclose until they >>> are actually fixed AND released (and there may be other stuff like >>> Java for Buisness releases which you don't want to disclose as well). >>> But for this working model it's easier to have separate trees for each >>> update release and for me that's the single (and understandable) >>> reason why you want to do it that way. >>> >>> But then I suggest to just tell the people the truth and everybody >>> will understand it instead of just beating around the bush. >>> >>> Just my opinion, >>> Volker >>> >>> >>> On Thu, Jun 16, 2011 at 10:51 PM, wrote: >>>> 2011/6/16 4:20 -0700, mark at klomp.org: >>>>> On Thu, 2011-06-16 at 12:18 +0200, Dalibor Topic wrote: >>>>>> Sure. The reason for new repos is to ensure that the materials associated >>>>>> with the JDK 7 Release Project remain available long-term rather than get >>>>>> buried under JDK 7 Update materials. >>>>> >>>>> What do you mean by buried? You just have to tag the repositories with >>>>> for each release/update to get exactly at the source at that time. Look >>>>> at how openjdk6 handles this. There is just one jdk6 forest with each >>>>> update release tagged. That is a much smoother model to follow IMHO. >>>>> Otherwise one quickly cannot find the forests through the trees :) >>>> >>>> There are other materials in the JDK 7 Project besides code. The various >>>> web pages describing schedule, features, milestones, etc., are likely to >>>> be of historical interest over the long term. If we use the existing JDK >>>> 7 Project for updates then that material would become harder to find, if >>>> not eventually lost altogether. The relevant URLs would almost certainly >>>> change. >>>> >>>> To put it another way, these are logically distinct Projects, with >>>> distinct participants, goals, and processes. Shoe-horning them into >>>> a single Project just risks confusing people. >>>> >>>> Finally, using the JDK 7 Project for updates would be inconsistent with >>>> the proposed Bylaws, which define a "JDK Release Project" as being for >>>> "new releases of Java SE Platform implementations". Update releases do >>>> not fit that definition. >>>> >>>> Aside from the issue of which Project to use, there will be multiple >>>> forests as Dalibor explains in his Q&A [1]: A mainline forest that's >>>> always open for incoming changesets, so that developers have somewhere >>>> to put their changes, and a forest for each actual update release, so >>>> that each release can be stabilized independently of the mainline. >>>> >>>> This is just the natural way to use a distributed VCS for parallel >>>> streams of development. Yes, Mercurial has branches, but they're >>>> generally not recommended by experts [2] and from what I've seen they >>>> haven't worked out all that well in practice. (If I recall correctly >>>> they were used briefly in IcedTea and then abandoned.) >>>> >>>> I honestly don't understand the aversion, expressed by some, to the >>>> creation of new forests. Disk space is cheap. What's the problem? >>>> >>>> - Mark >>>> >>>> >>>> [1] http://cr.openjdk.java.net/~robilad/jdk7u/7UpdateQAndA.txt >>>> [2] http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html#id386031 >>>> >> >> From dalibor.topic at oracle.com Fri Jun 17 11:44:26 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 17 Jun 2011 13:44:26 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> Message-ID: <4DFB3E1A.4040701@oracle.com> On 6/17/11 10:08 AM, Volker Simonis wrote: > Hi Mark (R), > > why so many words for so simple things? My impression is that this > discussion is just not honest from the Oracle part. Hi Volker, you are welcome to present arguments for doing things one way or another, like other participants in this discussion on this mailing list have done. But you're not welcome to question the honesty of other participants in the discussion on this mailing list, regardless who their employer is. That is, to put it as simply as I can, very rude. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From georges.saab at oracle.com Fri Jun 17 12:02:44 2011 From: georges.saab at oracle.com (Georges Saab) Date: Fri, 17 Jun 2011 14:02:44 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> <7319166E-FB7B-4C24-90F4-EC59C2F97458@oracle.com> Message-ID: <0407D9B7-8A2A-4976-A160-C0355D6A4DB3@oracle.com> Exactly, the update releases are often overlapping each other in development and testing. To make things even more fun this goes on for all JDK major version lines which have active updates occurring. And for security releases it needs to happen simultaneously across major JDK version lines where the fixes may be different, the end date committed a year in advance, varying degrees of severity and impact, all in a race with researchers who want to go public and those who want to exploit. Welcome to the sausage factory ;) On 17 jun 2011, at 11:53, Volker Simonis wrote: > Hi Georges, > > yes, I agree with you in the basic points. I think a part of the > confusion comes from the fact that you are generally working on > several update releases in parallel. In that case you absolutely need > different forests (or branches, code lines, you name it) so you can > stabilize one code line while you still integrate new changes into the > code line for the next update release. It may be not clear to the > community for example that the testing you do for one update release > needs several weeks and you don't want to stop the work on the next > but one release for this purpose. > > OpenJDK6 as mentioned by Mark Wielaard followed a simpler, linear > release model which could be well done with a single repository. > > Hopefully the development will really happen in the new repositories > as you promise and they will not be used just as a place where the > final results are dropped to. > > Regards, > Volker > > On Fri, Jun 17, 2011 at 11:22 AM, Georges Saab wrote: >> Hi Volker -- >> >> Actually this is the opposite. >> >> This model for SCM is a best known method employed in most professional software projects: >> 1. A main/head line for the next major release (JDK 8) >> 2. An update line for the last major version (7 update) >> 3. Off of which individual lines for each update release is taken (7uX) >> 4. If 'dot.dot' releases occur then an additional level of 2 and 3 is employed. >> >> This ensures that >> 1. There is always a place for fixes to go in - this avoids integration traffic jams and allows good continuous integration testing to do its job >> 2. Isolation is provided for release stabilization where it is possible to select which fixes come in as an update release is nearing completion. >> >> In general you want to create the release lines as late as possible (but not too late :)). Having them gives you the benefit of isolation at the cost of yet another merge for fixes. If you doubt the need for isolation at some point then there is clearly a more basic discussion that is needed :). >> >> The fact that this model is now surfaced in OpenJDK 7 shows IMHO that the intent is for this to be the place where the development is really happening rather than an intermediate >> rest stop for code on its way up or down stream. >> >> /GES >> >> On 17 jun 2011, at 10:08, Volker Simonis wrote: >> >>> Hi Mark (R), >>> >>> why so many words for so simple things? My impression is that this >>> discussion is just not honest from the Oracle part. Your work model >>> for JDK 6 has always been to prepare update releases in separate, >>> closed repositories and then, after they have been released, throw >>> them over into the OpenJDK. And probably you want to keep this model >>> for JDK7 as well. I'm not completely sure about the 'jdk' part, but >>> this was definitely true for the HotSpotExpress repositories. >>> >>> I don't want to criticise this working model at all. I understand that >>> there are security holes which you don't want to disclose until they >>> are actually fixed AND released (and there may be other stuff like >>> Java for Buisness releases which you don't want to disclose as well). >>> But for this working model it's easier to have separate trees for each >>> update release and for me that's the single (and understandable) >>> reason why you want to do it that way. >>> >>> But then I suggest to just tell the people the truth and everybody >>> will understand it instead of just beating around the bush. >>> >>> Just my opinion, >>> Volker >>> >>> >>> On Thu, Jun 16, 2011 at 10:51 PM, wrote: >>>> 2011/6/16 4:20 -0700, mark at klomp.org: >>>>> On Thu, 2011-06-16 at 12:18 +0200, Dalibor Topic wrote: >>>>>> Sure. The reason for new repos is to ensure that the materials associated >>>>>> with the JDK 7 Release Project remain available long-term rather than get >>>>>> buried under JDK 7 Update materials. >>>>> >>>>> What do you mean by buried? You just have to tag the repositories with >>>>> for each release/update to get exactly at the source at that time. Look >>>>> at how openjdk6 handles this. There is just one jdk6 forest with each >>>>> update release tagged. That is a much smoother model to follow IMHO. >>>>> Otherwise one quickly cannot find the forests through the trees :) >>>> >>>> There are other materials in the JDK 7 Project besides code. The various >>>> web pages describing schedule, features, milestones, etc., are likely to >>>> be of historical interest over the long term. If we use the existing JDK >>>> 7 Project for updates then that material would become harder to find, if >>>> not eventually lost altogether. The relevant URLs would almost certainly >>>> change. >>>> >>>> To put it another way, these are logically distinct Projects, with >>>> distinct participants, goals, and processes. Shoe-horning them into >>>> a single Project just risks confusing people. >>>> >>>> Finally, using the JDK 7 Project for updates would be inconsistent with >>>> the proposed Bylaws, which define a "JDK Release Project" as being for >>>> "new releases of Java SE Platform implementations". Update releases do >>>> not fit that definition. >>>> >>>> Aside from the issue of which Project to use, there will be multiple >>>> forests as Dalibor explains in his Q&A [1]: A mainline forest that's >>>> always open for incoming changesets, so that developers have somewhere >>>> to put their changes, and a forest for each actual update release, so >>>> that each release can be stabilized independently of the mainline. >>>> >>>> This is just the natural way to use a distributed VCS for parallel >>>> streams of development. Yes, Mercurial has branches, but they're >>>> generally not recommended by experts [2] and from what I've seen they >>>> haven't worked out all that well in practice. (If I recall correctly >>>> they were used briefly in IcedTea and then abandoned.) >>>> >>>> I honestly don't understand the aversion, expressed by some, to the >>>> creation of new forests. Disk space is cheap. What's the problem? >>>> >>>> - Mark >>>> >>>> >>>> [1] http://cr.openjdk.java.net/~robilad/jdk7u/7UpdateQAndA.txt >>>> [2] http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html#id386031 >>>> >> >> From dalibor.topic at oracle.com Fri Jun 17 11:46:24 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 17 Jun 2011 13:46:24 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: <1308308159.3266.28.camel@galactica> References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> <1308308159.3266.28.camel@galactica> Message-ID: <4DFB3E90.9080907@oracle.com> On 6/17/11 12:55 PM, Mario Torre wrote: > But I believe you see conspiracy where there is none, There is no need to have a thread in which people accuse each other of conspiracy theories on this mailing list. If you must have it, please take your dispute to private mail. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From georges.saab at oracle.com Fri Jun 17 12:02:44 2011 From: georges.saab at oracle.com (Georges Saab) Date: Fri, 17 Jun 2011 14:02:44 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> <7319166E-FB7B-4C24-90F4-EC59C2F97458@oracle.com> Message-ID: <0407D9B7-8A2A-4976-A160-C0355D6A4DB3@oracle.com> Exactly, the update releases are often overlapping each other in development and testing. To make things even more fun this goes on for all JDK major version lines which have active updates occurring. And for security releases it needs to happen simultaneously across major JDK version lines where the fixes may be different, the end date committed a year in advance, varying degrees of severity and impact, all in a race with researchers who want to go public and those who want to exploit. Welcome to the sausage factory ;) On 17 jun 2011, at 11:53, Volker Simonis wrote: > Hi Georges, > > yes, I agree with you in the basic points. I think a part of the > confusion comes from the fact that you are generally working on > several update releases in parallel. In that case you absolutely need > different forests (or branches, code lines, you name it) so you can > stabilize one code line while you still integrate new changes into the > code line for the next update release. It may be not clear to the > community for example that the testing you do for one update release > needs several weeks and you don't want to stop the work on the next > but one release for this purpose. > > OpenJDK6 as mentioned by Mark Wielaard followed a simpler, linear > release model which could be well done with a single repository. > > Hopefully the development will really happen in the new repositories > as you promise and they will not be used just as a place where the > final results are dropped to. > > Regards, > Volker > > On Fri, Jun 17, 2011 at 11:22 AM, Georges Saab wrote: >> Hi Volker -- >> >> Actually this is the opposite. >> >> This model for SCM is a best known method employed in most professional software projects: >> 1. A main/head line for the next major release (JDK 8) >> 2. An update line for the last major version (7 update) >> 3. Off of which individual lines for each update release is taken (7uX) >> 4. If 'dot.dot' releases occur then an additional level of 2 and 3 is employed. >> >> This ensures that >> 1. There is always a place for fixes to go in - this avoids integration traffic jams and allows good continuous integration testing to do its job >> 2. Isolation is provided for release stabilization where it is possible to select which fixes come in as an update release is nearing completion. >> >> In general you want to create the release lines as late as possible (but not too late :)). Having them gives you the benefit of isolation at the cost of yet another merge for fixes. If you doubt the need for isolation at some point then there is clearly a more basic discussion that is needed :). >> >> The fact that this model is now surfaced in OpenJDK 7 shows IMHO that the intent is for this to be the place where the development is really happening rather than an intermediate >> rest stop for code on its way up or down stream. >> >> /GES >> >> On 17 jun 2011, at 10:08, Volker Simonis wrote: >> >>> Hi Mark (R), >>> >>> why so many words for so simple things? My impression is that this >>> discussion is just not honest from the Oracle part. Your work model >>> for JDK 6 has always been to prepare update releases in separate, >>> closed repositories and then, after they have been released, throw >>> them over into the OpenJDK. And probably you want to keep this model >>> for JDK7 as well. I'm not completely sure about the 'jdk' part, but >>> this was definitely true for the HotSpotExpress repositories. >>> >>> I don't want to criticise this working model at all. I understand that >>> there are security holes which you don't want to disclose until they >>> are actually fixed AND released (and there may be other stuff like >>> Java for Buisness releases which you don't want to disclose as well). >>> But for this working model it's easier to have separate trees for each >>> update release and for me that's the single (and understandable) >>> reason why you want to do it that way. >>> >>> But then I suggest to just tell the people the truth and everybody >>> will understand it instead of just beating around the bush. >>> >>> Just my opinion, >>> Volker >>> >>> >>> On Thu, Jun 16, 2011 at 10:51 PM, wrote: >>>> 2011/6/16 4:20 -0700, mark at klomp.org: >>>>> On Thu, 2011-06-16 at 12:18 +0200, Dalibor Topic wrote: >>>>>> Sure. The reason for new repos is to ensure that the materials associated >>>>>> with the JDK 7 Release Project remain available long-term rather than get >>>>>> buried under JDK 7 Update materials. >>>>> >>>>> What do you mean by buried? You just have to tag the repositories with >>>>> for each release/update to get exactly at the source at that time. Look >>>>> at how openjdk6 handles this. There is just one jdk6 forest with each >>>>> update release tagged. That is a much smoother model to follow IMHO. >>>>> Otherwise one quickly cannot find the forests through the trees :) >>>> >>>> There are other materials in the JDK 7 Project besides code. The various >>>> web pages describing schedule, features, milestones, etc., are likely to >>>> be of historical interest over the long term. If we use the existing JDK >>>> 7 Project for updates then that material would become harder to find, if >>>> not eventually lost altogether. The relevant URLs would almost certainly >>>> change. >>>> >>>> To put it another way, these are logically distinct Projects, with >>>> distinct participants, goals, and processes. Shoe-horning them into >>>> a single Project just risks confusing people. >>>> >>>> Finally, using the JDK 7 Project for updates would be inconsistent with >>>> the proposed Bylaws, which define a "JDK Release Project" as being for >>>> "new releases of Java SE Platform implementations". Update releases do >>>> not fit that definition. >>>> >>>> Aside from the issue of which Project to use, there will be multiple >>>> forests as Dalibor explains in his Q&A [1]: A mainline forest that's >>>> always open for incoming changesets, so that developers have somewhere >>>> to put their changes, and a forest for each actual update release, so >>>> that each release can be stabilized independently of the mainline. >>>> >>>> This is just the natural way to use a distributed VCS for parallel >>>> streams of development. Yes, Mercurial has branches, but they're >>>> generally not recommended by experts [2] and from what I've seen they >>>> haven't worked out all that well in practice. (If I recall correctly >>>> they were used briefly in IcedTea and then abandoned.) >>>> >>>> I honestly don't understand the aversion, expressed by some, to the >>>> creation of new forests. Disk space is cheap. What's the problem? >>>> >>>> - Mark >>>> >>>> >>>> [1] http://cr.openjdk.java.net/~robilad/jdk7u/7UpdateQAndA.txt >>>> [2] http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html#id386031 >>>> >> >> From dalibor.topic at oracle.com Fri Jun 17 11:44:26 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 17 Jun 2011 13:44:26 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> Message-ID: <4DFB3E1A.4040701@oracle.com> On 6/17/11 10:08 AM, Volker Simonis wrote: > Hi Mark (R), > > why so many words for so simple things? My impression is that this > discussion is just not honest from the Oracle part. Hi Volker, you are welcome to present arguments for doing things one way or another, like other participants in this discussion on this mailing list have done. But you're not welcome to question the honesty of other participants in the discussion on this mailing list, regardless who their employer is. That is, to put it as simply as I can, very rude. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From volker.simonis at gmail.com Fri Jun 17 14:18:22 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jun 2011 16:18:22 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: <1308308159.3266.28.camel@galactica> References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> <1308308159.3266.28.camel@galactica> Message-ID: Sorry, I apologize if my mail was to rude or questioned the integrity of anybody on this list. I definitely didn't wanted to hurt anybody. I'm just not very satisfied with how the things are going with the HSX repositories compared to the HS versions in the official Oracle JDK and wanted to prevent this situation for the JDK 7 update releases. If my fears are without cause - that's just great! See my further comments inline: On Fri, Jun 17, 2011 at 12:55 PM, Mario Torre wrote: > Il giorno ven, 17/06/2011 alle 10.08 +0200, Volker Simonis ha scritto: >> Hi Mark (R), >> >> why so many words for ?so simple things? My impression is that this >> discussion is just not honest from the Oracle part. Your work model >> for JDK 6 has always been to prepare update releases in separate, >> closed repositories and then, after they have been released, throw >> them over into the OpenJDK. And probably you want to keep this model >> for JDK7 as well. I'm not completely sure about the 'jdk' part, but >> this was definitely true for the HotSpotExpress repositories. >> >> I don't want to criticise this working model at all. I understand that >> there are security holes which you don't want to disclose until they >> are actually fixed AND released (and there may be other stuff like >> Java for Buisness releases which you don't want to disclose as well). >> But for this working model it's easier to have separate trees for each >> update release and for me that's the single (and understandable) >> reason why you want to do it that way. >> >> But then I suggest to just tell the people the truth and everybody >> will understand it instead of just beating around the bush. >> >> Just my opinion, >> Volker > > I firstly misunderstood the way this would have been implemented, > because (bad Oracle!) it wasn't communicated right in the first place I > guess... > > But I believe you see conspiracy where there is none, after all, Oracle > has all the rights (both legally and morally) to have closed source > branches in my opinion, and this doesn't really impact much the open > developments, especially now that it seems that the true RI will be > OpenJDK and not the closed version. > As you can read in Henriks blog at http://blogs.oracle.com/henrik/entry/moving_to_openjdk_as_the : "The RI is built once when the specification is finalized and not touched again (no updates, no patches, no security fixes)...". So in my opinion there will be an impact for on the 'open development' as you call it if you don't get updates, patches, security fixes, ... But according to the ongoing discussion on this thread, that just what the update repositories are for. So lets hope all will work smoothly:) > I understood that the model would have been a branch for each release, > which host development for the next branch, which is not really very > well sustainable (but once again, there is nothing inherently wrong with > it either). > > On the other end, I now seem to understand that the reality is a branch > for JDK development (jdk7u), from which you get release branches, but > the main development still happens in jdk7u, so in my opinion is just > lots of noise for nothing :) > > Btw, it doesn't really change much if you get dev branches or not, if > Oracle wants to push for the closed development it can do it anyway, so > I really fail to see the point of your mail. > Just have look at he HSX (HotSpot express) repositories on hg.openjdk.java.net/ and compare the changesets there with the changesets which went into the HSX version in the official Oracle JDK6uXX versions (http://www.oracle.com/technetwork/java/javase/releasenotes-136954.html). The difference that you'll notice is exactly the point of my mail. > Cheers, > Mario > > P.S. I hope things will happen in the open and I believe is correct to > push for this of course, I just don't see how this mail is related, > other than ask that this kind of discussion takes place in public next > time before getting the results of the proposal as a matter of fact. > However, in this specific case I believe there was just some > misunderstanding in the communication system. > > > From dalibor.topic at oracle.com Fri Jun 17 11:46:24 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 17 Jun 2011 13:46:24 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: <1308308159.3266.28.camel@galactica> References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> <1308308159.3266.28.camel@galactica> Message-ID: <4DFB3E90.9080907@oracle.com> On 6/17/11 12:55 PM, Mario Torre wrote: > But I believe you see conspiracy where there is none, There is no need to have a thread in which people accuse each other of conspiracy theories on this mailing list. If you must have it, please take your dispute to private mail. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From georges.saab at oracle.com Fri Jun 17 12:02:44 2011 From: georges.saab at oracle.com (Georges Saab) Date: Fri, 17 Jun 2011 14:02:44 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> <7319166E-FB7B-4C24-90F4-EC59C2F97458@oracle.com> Message-ID: <0407D9B7-8A2A-4976-A160-C0355D6A4DB3@oracle.com> Exactly, the update releases are often overlapping each other in development and testing. To make things even more fun this goes on for all JDK major version lines which have active updates occurring. And for security releases it needs to happen simultaneously across major JDK version lines where the fixes may be different, the end date committed a year in advance, varying degrees of severity and impact, all in a race with researchers who want to go public and those who want to exploit. Welcome to the sausage factory ;) On 17 jun 2011, at 11:53, Volker Simonis wrote: > Hi Georges, > > yes, I agree with you in the basic points. I think a part of the > confusion comes from the fact that you are generally working on > several update releases in parallel. In that case you absolutely need > different forests (or branches, code lines, you name it) so you can > stabilize one code line while you still integrate new changes into the > code line for the next update release. It may be not clear to the > community for example that the testing you do for one update release > needs several weeks and you don't want to stop the work on the next > but one release for this purpose. > > OpenJDK6 as mentioned by Mark Wielaard followed a simpler, linear > release model which could be well done with a single repository. > > Hopefully the development will really happen in the new repositories > as you promise and they will not be used just as a place where the > final results are dropped to. > > Regards, > Volker > > On Fri, Jun 17, 2011 at 11:22 AM, Georges Saab wrote: >> Hi Volker -- >> >> Actually this is the opposite. >> >> This model for SCM is a best known method employed in most professional software projects: >> 1. A main/head line for the next major release (JDK 8) >> 2. An update line for the last major version (7 update) >> 3. Off of which individual lines for each update release is taken (7uX) >> 4. If 'dot.dot' releases occur then an additional level of 2 and 3 is employed. >> >> This ensures that >> 1. There is always a place for fixes to go in - this avoids integration traffic jams and allows good continuous integration testing to do its job >> 2. Isolation is provided for release stabilization where it is possible to select which fixes come in as an update release is nearing completion. >> >> In general you want to create the release lines as late as possible (but not too late :)). Having them gives you the benefit of isolation at the cost of yet another merge for fixes. If you doubt the need for isolation at some point then there is clearly a more basic discussion that is needed :). >> >> The fact that this model is now surfaced in OpenJDK 7 shows IMHO that the intent is for this to be the place where the development is really happening rather than an intermediate >> rest stop for code on its way up or down stream. >> >> /GES >> >> On 17 jun 2011, at 10:08, Volker Simonis wrote: >> >>> Hi Mark (R), >>> >>> why so many words for so simple things? My impression is that this >>> discussion is just not honest from the Oracle part. Your work model >>> for JDK 6 has always been to prepare update releases in separate, >>> closed repositories and then, after they have been released, throw >>> them over into the OpenJDK. And probably you want to keep this model >>> for JDK7 as well. I'm not completely sure about the 'jdk' part, but >>> this was definitely true for the HotSpotExpress repositories. >>> >>> I don't want to criticise this working model at all. I understand that >>> there are security holes which you don't want to disclose until they >>> are actually fixed AND released (and there may be other stuff like >>> Java for Buisness releases which you don't want to disclose as well). >>> But for this working model it's easier to have separate trees for each >>> update release and for me that's the single (and understandable) >>> reason why you want to do it that way. >>> >>> But then I suggest to just tell the people the truth and everybody >>> will understand it instead of just beating around the bush. >>> >>> Just my opinion, >>> Volker >>> >>> >>> On Thu, Jun 16, 2011 at 10:51 PM, wrote: >>>> 2011/6/16 4:20 -0700, mark at klomp.org: >>>>> On Thu, 2011-06-16 at 12:18 +0200, Dalibor Topic wrote: >>>>>> Sure. The reason for new repos is to ensure that the materials associated >>>>>> with the JDK 7 Release Project remain available long-term rather than get >>>>>> buried under JDK 7 Update materials. >>>>> >>>>> What do you mean by buried? You just have to tag the repositories with >>>>> for each release/update to get exactly at the source at that time. Look >>>>> at how openjdk6 handles this. There is just one jdk6 forest with each >>>>> update release tagged. That is a much smoother model to follow IMHO. >>>>> Otherwise one quickly cannot find the forests through the trees :) >>>> >>>> There are other materials in the JDK 7 Project besides code. The various >>>> web pages describing schedule, features, milestones, etc., are likely to >>>> be of historical interest over the long term. If we use the existing JDK >>>> 7 Project for updates then that material would become harder to find, if >>>> not eventually lost altogether. The relevant URLs would almost certainly >>>> change. >>>> >>>> To put it another way, these are logically distinct Projects, with >>>> distinct participants, goals, and processes. Shoe-horning them into >>>> a single Project just risks confusing people. >>>> >>>> Finally, using the JDK 7 Project for updates would be inconsistent with >>>> the proposed Bylaws, which define a "JDK Release Project" as being for >>>> "new releases of Java SE Platform implementations". Update releases do >>>> not fit that definition. >>>> >>>> Aside from the issue of which Project to use, there will be multiple >>>> forests as Dalibor explains in his Q&A [1]: A mainline forest that's >>>> always open for incoming changesets, so that developers have somewhere >>>> to put their changes, and a forest for each actual update release, so >>>> that each release can be stabilized independently of the mainline. >>>> >>>> This is just the natural way to use a distributed VCS for parallel >>>> streams of development. Yes, Mercurial has branches, but they're >>>> generally not recommended by experts [2] and from what I've seen they >>>> haven't worked out all that well in practice. (If I recall correctly >>>> they were used briefly in IcedTea and then abandoned.) >>>> >>>> I honestly don't understand the aversion, expressed by some, to the >>>> creation of new forests. Disk space is cheap. What's the problem? >>>> >>>> - Mark >>>> >>>> >>>> [1] http://cr.openjdk.java.net/~robilad/jdk7u/7UpdateQAndA.txt >>>> [2] http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html#id386031 >>>> >> >> From neugens.limasoftware at gmail.com Fri Jun 17 14:48:34 2011 From: neugens.limasoftware at gmail.com (=?utf-8?B?bmV1Z2Vucy5saW1hc29mdHdhcmVAZ21haWwuY29t?=) Date: Fri, 17 Jun 2011 16:48:34 +0200 Subject: =?utf-8?B?UmU6IFByb2plY3QgUHJvcG9zYWw6IEpESyA3IFVwZGF0ZQ==?= Message-ID: <4dfb697d.41c6e30a.35c2.5506@mx.google.com> Hi Dalibor, Of course, I didn't mean to be offensive either. There was a song from Soulwax that is called Conversation Intercom :) which quite well say it and the good Simon Phipps explained that kind of issue at fosdem this year too. I apologize if it sounded otherwise, and let's get back to the original thread now. Mario -- Sent from HTC Desire... pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ ----- Reply message ----- Da: "Dalibor Topic" Data: ven, giu 17, 2011 13:46 Oggetto: Project Proposal: JDK 7 Update A: On 6/17/11 12:55 PM, Mario Torre wrote: > But I believe you see conspiracy where there is none, There is no need to have a thread in which people accuse each other of conspiracy theories on this mailing list. If you must have it, please take your dispute to private mail. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From David.Holmes at oracle.com Sat Jun 18 05:44:19 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 18 Jun 2011 15:44:19 +1000 Subject: Project Proposal: JDK 7 Update In-Reply-To: References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> <1308308159.3266.28.camel@galactica> Message-ID: <4DFC3B33.4050500@oracle.com> Volker Simonis said the following on 06/18/11 00:18: > Sorry, I apologize if my mail was to rude or questioned the integrity > of anybody on this list. I definitely didn't wanted to hurt anybody. > > I'm just not very satisfied with how the things are going with the HSX > repositories compared to the HS versions in the official Oracle JDK > and wanted to prevent this situation for the JDK 7 update releases. If > my fears are without cause - that's just great! > Just have look at he HSX (HotSpot express) repositories on > hg.openjdk.java.net/ and compare the changesets there with the > changesets which went into the HSX version in the official Oracle > JDK6uXX versions > (http://www.oracle.com/technetwork/java/javase/releasenotes-136954.html). > The difference that you'll notice is exactly the point of my mail. I'm afraid I'm not getting your point at all, what exactly is your concern with the HSX release model as it relates to the JDK6 update train? What is it that you see, or don't see, in the release notes that concerns you? Regards, David Holmes From volker.simonis at gmail.com Sat Jun 18 16:22:31 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 18 Jun 2011 18:22:31 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: <4DFC3B33.4050500@oracle.com> References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> <1308308159.3266.28.camel@galactica> <4DFC3B33.4050500@oracle.com> Message-ID: On Sat, Jun 18, 2011 at 7:44 AM, David Holmes wrote: > Volker Simonis said the following on 06/18/11 00:18: >> >> Sorry, I apologize if my mail was to rude or questioned the integrity >> of anybody on this list. I definitely didn't wanted to hurt anybody. >> >> I'm just not very satisfied with how the things are going with the HSX >> repositories compared to the HS versions in the official Oracle JDK >> and wanted to prevent this situation for the JDK 7 update releases. If >> my fears are without cause - that's just great! > > >> >> Just have look at he HSX (HotSpot express) repositories on >> hg.openjdk.java.net/ and compare the changesets there with the >> changesets which went into the HSX version in the official Oracle >> JDK6uXX versions >> (http://www.oracle.com/technetwork/java/javase/releasenotes-136954.html). >> The difference that you'll notice is exactly the point of my mail. > > I'm afraid I'm not getting your point at all, what exactly is your concern > with the HSX release model as it relates to the JDK6 update train? What is > it that you see, or don't see, in the release notes that concerns you? > There are changes in the official 6uXX releases which don't get backported to the corresponding OpenJDK hsx repositories. These are mainly security fixes but I also recall another example which was related to compressed strings (see http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-March/003907.html). As you probaly now, the official JDK6 update releases contain HSX version with incremented sub-numbers (HS20.1bxx, HS20.2bxx). They are all different from the HSX repository in the OpenJDK which usually remain at a certain build number and dont increment the sub-number. I would definitely prefer to have one "golden" HSX repositotry in the OpenJDK which contains ALL the changes of the corresponding HSX versions from the closed JDK (maybe with a certain delay for security fixes which would be no problem). > Regards, > David Holmes > From joe.darcy at oracle.com Sat Jun 18 18:01:56 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 18 Jun 2011 11:01:56 -0700 Subject: Project Proposal: JDK 7 Update In-Reply-To: References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> <1308308159.3266.28.camel@galactica> <4DFC3B33.4050500@oracle.com> Message-ID: <4DFCE814.5020807@oracle.com> Volker Simonis wrote: > On Sat, Jun 18, 2011 at 7:44 AM, David Holmes wrote: > >> Volker Simonis said the following on 06/18/11 00:18: >> >>> Sorry, I apologize if my mail was to rude or questioned the integrity >>> of anybody on this list. I definitely didn't wanted to hurt anybody. >>> >>> I'm just not very satisfied with how the things are going with the HSX >>> repositories compared to the HS versions in the official Oracle JDK >>> and wanted to prevent this situation for the JDK 7 update releases. If >>> my fears are without cause - that's just great! >>> >> >> >>> Just have look at he HSX (HotSpot express) repositories on >>> hg.openjdk.java.net/ and compare the changesets there with the >>> changesets which went into the HSX version in the official Oracle >>> JDK6uXX versions >>> (http://www.oracle.com/technetwork/java/javase/releasenotes-136954.html). >>> The difference that you'll notice is exactly the point of my mail. >>> >> I'm afraid I'm not getting your point at all, what exactly is your concern >> with the HSX release model as it relates to the JDK6 update train? What is >> it that you see, or don't see, in the release notes that concerns you? >> >> > > There are changes in the official 6uXX releases which don't get > backported to the corresponding OpenJDK hsx repositories. These are > mainly security fixes but I also recall another example which was > related to compressed strings (see > http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-March/003907.html). > All the relevant security fixes do get ported to OpenJDK 6. An OpenJDK 6 build is usually promoted shortly after one of the synchronized security releases of the JDK goes out. -Joe From philip.race at oracle.com Sun Jun 19 04:34:56 2011 From: philip.race at oracle.com (Phil Race) Date: Sat, 18 Jun 2011 21:34:56 -0700 Subject: Project Proposal: JDK 7 Update In-Reply-To: References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> <1308308159.3266.28.camel@galactica> <4DFC3B33.4050500@oracle.com> Message-ID: <4DFD7C70.9030806@oracle.com> Not talking about hotspot specifically, but more generally, SFAIK all relevant security fixes have been backported to 6-open. And 6-open in fact has a lot of fixes that are *not* in the commercial versions. Some of those are its origins as a very early 7. Some are from backports that were OKed for 6-open but really not considered that critical for JDK6. But I'm very sure 6 updates have (non-security) fixes not in 6-open too. So its all very messt. Now something of a digression .. I think a lot of that was down to the unexpectedly long cycle for JDK 7 and the unrelated forests for 6-open and 6 updates (as noted above) But release managers carefully scrutinise requested backports from JDK8 to a 7 update because updates have less time to bake. So in the 7 update cycle if everything is based off the same forests we should expect that management of the content of these will need to be merged too. -phil. On 6/18/11 9:22 AM, Volker Simonis wrote: > On Sat, Jun 18, 2011 at 7:44 AM, David Holmes wrote: >> Volker Simonis said the following on 06/18/11 00:18: >>> Sorry, I apologize if my mail was to rude or questioned the integrity >>> of anybody on this list. I definitely didn't wanted to hurt anybody. >>> >>> I'm just not very satisfied with how the things are going with the HSX >>> repositories compared to the HS versions in the official Oracle JDK >>> and wanted to prevent this situation for the JDK 7 update releases. If >>> my fears are without cause - that's just great! >> >>> Just have look at he HSX (HotSpot express) repositories on >>> hg.openjdk.java.net/ and compare the changesets there with the >>> changesets which went into the HSX version in the official Oracle >>> JDK6uXX versions >>> (http://www.oracle.com/technetwork/java/javase/releasenotes-136954.html). >>> The difference that you'll notice is exactly the point of my mail. >> I'm afraid I'm not getting your point at all, what exactly is your concern >> with the HSX release model as it relates to the JDK6 update train? What is >> it that you see, or don't see, in the release notes that concerns you? >> > There are changes in the official 6uXX releases which don't get > backported to the corresponding OpenJDK hsx repositories. These are > mainly security fixes but I also recall another example which was > related to compressed strings (see > http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-March/003907.html). > > As you probaly now, the official JDK6 update releases contain HSX > version with incremented sub-numbers (HS20.1bxx, HS20.2bxx). They are > all different from the HSX repository in the OpenJDK which usually > remain at a certain build number and dont increment the sub-number. I > would definitely prefer to have one "golden" HSX repositotry in the > OpenJDK which contains ALL the changes of the corresponding HSX > versions from the closed JDK (maybe with a certain delay for security > fixes which would be no problem). > > >> Regards, >> David Holmes >> From David.Holmes at oracle.com Mon Jun 20 00:38:55 2011 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 20 Jun 2011 10:38:55 +1000 Subject: Project Proposal: JDK 7 Update In-Reply-To: References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> <1308308159.3266.28.camel@galactica> <4DFC3B33.4050500@oracle.com> Message-ID: <4DFE969F.7010409@oracle.com> Volker Simonis said the following on 06/19/11 02:22: > On Sat, Jun 18, 2011 at 7:44 AM, David Holmes wrote: >> Volker Simonis said the following on 06/18/11 00:18: >>> Sorry, I apologize if my mail was to rude or questioned the integrity >>> of anybody on this list. I definitely didn't wanted to hurt anybody. >>> >>> I'm just not very satisfied with how the things are going with the HSX >>> repositories compared to the HS versions in the official Oracle JDK >>> and wanted to prevent this situation for the JDK 7 update releases. If >>> my fears are without cause - that's just great! >> >>> Just have look at he HSX (HotSpot express) repositories on >>> hg.openjdk.java.net/ and compare the changesets there with the >>> changesets which went into the HSX version in the official Oracle >>> JDK6uXX versions >>> (http://www.oracle.com/technetwork/java/javase/releasenotes-136954.html). >>> The difference that you'll notice is exactly the point of my mail. >> I'm afraid I'm not getting your point at all, what exactly is your concern >> with the HSX release model as it relates to the JDK6 update train? What is >> it that you see, or don't see, in the release notes that concerns you? >> > > There are changes in the official 6uXX releases which don't get > backported to the corresponding OpenJDK hsx repositories. These are > mainly security fixes but I also recall another example which was > related to compressed strings (see > http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-March/003907.html). > > As you probaly now, the official JDK6 update releases contain HSX > version with incremented sub-numbers (HS20.1bxx, HS20.2bxx). They are > all different from the HSX repository in the OpenJDK which usually > remain at a certain build number and dont increment the sub-number. I > would definitely prefer to have one "golden" HSX repositotry in the > OpenJDK which contains ALL the changes of the corresponding HSX > versions from the closed JDK (maybe with a certain delay for security > fixes which would be no problem). You seem to be complaining not about missing backports, but the fact that the official 6uX releases contain non-open-source code. The public HSX repositories contain the openJDK code. The HSX 20.1, 20.2 etc are closed internal branches/forks from those open versions. David > >> Regards, >> David Holmes >> From ahughes at redhat.com Tue Jun 21 13:36:01 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Tue, 21 Jun 2011 14:36:01 +0100 Subject: Project Proposal: JDK 7 Update In-Reply-To: <1308223210.3183.3.camel@springer.wildebeest.org> References: <4DF931CE.1030709@oracle.com> <1308181077.30719.2.camel@springer.wildebeest.org> <20110616004627.GG9245@rivendell.middle-earth.co.uk> <4DF9D861.8000808@oracle.com> <1308223210.3183.3.camel@springer.wildebeest.org> Message-ID: <20110621133601.GA28458@rivendell.middle-earth.co.uk> On 13:20 Thu 16 Jun , Mark Wielaard wrote: > On Thu, 2011-06-16 at 12:18 +0200, Dalibor Topic wrote: > > On 6/16/11 2:46 AM, Dr Andrew John Hughes wrote: > > > On 01:37 Thu 16 Jun , Mark Wielaard wrote: > > >> On Thu, 2011-06-16 at 00:27 +0200, Dalibor Topic wrote: > > >>> This Project will be used for developing updates to JDK 7. > > >>> > > >>> This work will be done in a separate set of repositories. > > >> > > >> Please not yet another set of repositories. You can just tag the current > > >> jdk7 repositories when you release/update. > > >> > > > > > > Yes, why does this need new repositories? Please explain. > > > > Sure. The reason for new repos is to ensure that the materials associated > > with the JDK 7 Release Project remain available long-term rather than get > > buried under JDK 7 Update materials. > > What do you mean by buried? You just have to tag the repositories with > for each release/update to get exactly at the source at that time. Look > at how openjdk6 handles this. There is just one jdk6 forest with each > update release tagged. That is a much smoother model to follow IMHO. > Otherwise one quickly cannot find the forests through the trees :) > I wouldn't use OpenJDK6 for comparison. Oracle don't use it and IcedTea only uses it as a base and then applies a mass of patches. It's hardly a central point for lots of development work, as I expect the various OpenJDK7 branches will be. If you look at IcedTea instead, you will see we do the same thing and there are currently four active branches (1.8, 1.9, 1.10 and HEAD). This could have been explained more clearly to start with (and the whole project notion just gets a bit silly IMHO) but I think it makes sense now it has been explained. It leaves the flexibility to still be able to add a few security fixes to the original OpenJDK7 or an update release, even after later updates have appeared with further fixes and new features. Not everyone wants the latest and greatest. Some want a stable base with the latest security holes closed. > Cheers, > > Mark > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Tue Jun 21 13:37:46 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Tue, 21 Jun 2011 14:37:46 +0100 Subject: Project Proposal: JDK 7 Update In-Reply-To: <4DFCE814.5020807@oracle.com> References: <1308223210.3183.3.camel@springer.wildebeest.org> <20110616205146.83F352267@eggemoggin.niobe.net> <1308308159.3266.28.camel@galactica> <4DFC3B33.4050500@oracle.com> <4DFCE814.5020807@oracle.com> Message-ID: <20110621133746.GB28458@rivendell.middle-earth.co.uk> On 11:01 Sat 18 Jun , Joe Darcy wrote: snip... > > All the relevant security fixes do get ported to OpenJDK 6. An OpenJDK > 6 build is usually promoted shortly after one of the synchronized > security releases of the JDK goes out. > So is there going to be such a release? It's now two weeks since the last batch of security updates and no new OpenJDK6 bundle seems to have appeared. It's a good job we don't wait for this in preparing updates for IcedTea. > -Joe -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dalibor.topic at oracle.com Tue Jun 21 14:36:52 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 21 Jun 2011 16:36:52 +0200 Subject: Project Proposal: JDK 7 Update In-Reply-To: <20110621133601.GA28458@rivendell.middle-earth.co.uk> References: <4DF931CE.1030709@oracle.com> <1308181077.30719.2.camel@springer.wildebeest.org> <20110616004627.GG9245@rivendell.middle-earth.co.uk> <4DF9D861.8000808@oracle.com> <1308223210.3183.3.camel@springer.wildebeest.org> <20110621133601.GA28458@rivendell.middle-earth.co.uk> Message-ID: <4E00AC84.3030702@oracle.com> On 6/21/11 3:36 PM, Dr Andrew John Hughes wrote: > If you look at IcedTea instead, you will see > we do the same thing and there are currently four active branches > (1.8, 1.9, 1.10 and HEAD). Yeah, that was my impression too. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From mark.reinhold at oracle.com Thu Jun 23 16:30:29 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 23 Jun 2011 09:30:29 -0700 Subject: JDK Enhancement-Proposal & Roadmap Process -- DRAFT Message-ID: <20110623163029.18A225A8B@eggemoggin.niobe.net> Returning to a thread I started back in March [1], I've written up and posted the first draft of a process for collecting, reviewing, sorting, and recording the results of proposals for enhancements to the JDK and for related efforts, such as process and infrastructure improvements. As a reminder, here are the goals: - As lightweight as possible. - Simple mechanics. - Version-controlled, so that changes can be tracked. - Open to all Committers, with transparent decision-making. - The basic format should not be too different from (a simplified form of) the old Sun "one-pager" template [2], with which many are already familiar. - An approved proposal should be able to serve as the authoritative source of the summary and reference information needed for related documents such as the release feature list [3] and the Platform Umbrella JSR specification [4]. There are three documents: - Process definition http://cr.openjdk.java.net/~mr/jep/jep-process.html - Proposal template http://cr.openjdk.java.net/~mr/jep/jep-template - Example proposal http://cr.openjdk.java.net/~mr/jep/draft-mcimadamore-inference-01.md This draft has been reviewed by just a few people so far; my thanks to Brian Goetz, Paul Hohensee, Georges Saab, and Mikael Vidstedt for their feedback. Acknowledgement is also due to the Python community, from whose PEP process [5] many useful ideas were adopted. If you have comments or suggestions on this draft then please send them in a public reply to this message by Thursday 7 July 2011. I'd like to put this process in place shortly thereafter. NOTE: This is not a solicitation for specific proposals! That will come later, after this process is in place. - Mark [1] http://mail.openjdk.java.net/pipermail/discuss/2011-March/001704.html [2] http://hub.opensolaris.org/bin/view/Community+Group+arc/onepager [3] E.g., http://openjdk.java.net/projects/jdk7/features/ [4] E.g., http://jcp.org/en/jsr/detail?id=336 [5] http://python.org/dev/peps/pep-0001/ From mark.reinhold at oracle.com Thu Jun 23 20:45:25 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 23 Jun 2011 13:45:25 -0700 Subject: Project Proposal: JDK 7 Update In-Reply-To: mark@klomp.org; Thu, 16 Jun 2011 23:31:38 +0200; <1308259898.8032.28.camel@springer.wildebeest.org> Message-ID: <20110623204525.CAE915A8B@eggemoggin.niobe.net> 2011/6/16 14:31 -0700, mark at klomp.org: > On Thu, 2011-06-16 at 13:51 -0700, mark.reinhold at oracle.com wrote: >> ... >> >> I honestly don't understand the aversion, expressed by some, to the >> creation of new forests. Disk space is cheap. What's the problem? > > Changing names and locations is always a bit confusing. That is just it. > And it is just that jdk6 is going so well and is pleasant to work with > because it is just one forest with each update tagged that made me happy > with that way of working. So personally I would like to see that also be > used to continue jdk7 if possible. It would be shame to break up > something we are used to that is all. Using just one forest for JDK 7 updates isn't realistic. That approach worked for (Open) JDK 6 because so few people were involved and there were no tight deadlines. That won't be the case for the JDK 7 updates. > Wouldn't it be an idea to instead of branching off for the next update, > to branch off and archive jdk7 1.0 on a special release page/URL under > http://openjdk.java.net/projects/jdk7/releases/1.0/ when we are > satisfied it is finished, put some tar balls, the archived feature, > milestones, builds and calender under it and then keep the jdk7 project > as being the update project? From a developer standpoint that seems > nicer to keep up with than having to change every time there is a new > update just to keep on top of the latest jdk7 development. Ah, perhaps that's part of the confusion. The proposal is not to create a brand-new Project for every single JDK 7 update release, but rather to have one Project for all JDK 7 update releases. So there's a one-time change for developers who transition from working on JDK 7 itself to working on the update releases, but no further changes after that. > BTW. I am not dead against having a new project. If people feel that is > the best thing to do to keep improving jdk7. I am just surprised because > it feels much more natural to just keep using the jdk7 project to work > on jdk7 stuff instead of having to go through all the trouble of setting > up a new project and repositories. But I am sure you feel surprised the > same way, just in reverse :) I'm both surprised, and not. - Mark From stuart.marks at oracle.com Tue Jun 28 19:17:07 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 28 Jun 2011 12:17:07 -0700 Subject: JDK Enhancement-Proposal & Roadmap Process -- DRAFT In-Reply-To: <20110623163029.18A225A8B@eggemoggin.niobe.net> References: <20110623163029.18A225A8B@eggemoggin.niobe.net> Message-ID: <4E0A28B3.1070208@oracle.com> Hi Mark, I have a question about how the process, and specifically the proposal template, deals with changes of a "horizontal" or "cross-cutting" nature. From the template, > - Proposal template > http://cr.openjdk.java.net/~mr/jep/jep-template there is a fairly specific hierarchy of areas and components: // We use two-part identifiers of the form /. // // The areas are: vm, core, client, web // // The components depend upon the areas, as follows: // // vm: comp, gc, rt, svc // core: lang, libs, i18n, net, sec, svc // client: gui, sound // web: jaxp, jaxb, jaxws, corba This scheme lends itself well to enhancements in a specific component, as most enhancements are. But there's a different kind of enhancement that doesn't seem to fit well into the area/component form. Consider the following example proposal: ensure that all Throwable subclasses in the JDK have at least the standard set of constructor overloads, including no-arg, message, cause, and (message, cause). (Obviously I'm not interested in discussing the merits of this proposal at this point; this is merely an example of a horizontal change.) The point of this proposal is that it wants to establish a global property over all Java SE APIs. It's pretty easy to find examples in different parts of the system that don't conform (see java.rmi.server.ServerNotActiveException and java.awt.FontFormatException to name just two). A proposal like this doesn't seem to fit into a single area/component. It seems unreasonable to require multiple similar proposals for different components. I'm not sure of a good alternative though. Maybe we create a new pseudo-component or even pseudo-area to indicate proposals of a horizontal nature. Or perhaps we just say core/* or even */* (though the latter does seem unlikely). By the way, I don't think this example is a special case. The Coinification work I did in JDK 7 (upgrade library code to use diamond, upgrade library code to use try-with-resources, etc.) is another example of a horizontally-oriented project. I also have several others in my back pocket. :-) Another minor concern I have is the actual breakdown of components in the core area. Consider things like io, nio, and rmi. Do they fit into libs and net, or are they their own components? This isn't really a big deal; we just need to make sure we've established the right set of items in the area/component hierarchy. Thanks. s'marks