Project Proposal: JDK 7 Update

[Volker Simonis]

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
>