Project Proposal: JDK 7 Update

Georges Saab georges.saab at oracle.com
Fri Jun 17 12:02:44 UTC 2011


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 <volker.simonis at gmail.com> 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 <georges.saab at oracle.com> 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 <volker.simonis at gmail.com> 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,  <mark.reinhold at oracle.com> 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
>>>> 
>> 
>> 



More information about the discuss mailing list