From quanah at zimbra.com Thu Nov 12 03:42:23 2015
From: quanah at zimbra.com (Quanah Gibson-Mount)
Date: Wed, 11 Nov 2015 19:42:23 -0800
Subject: Coherent release process
Message-ID: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]>
Hi,
I was wondering if/when the OpenJDK project may develop a more coherent
release plan? Right now, there seems to be no consistent strategy, which
makes it very difficult for downstream consumers of OpenJDK to be able to
reliably build out new OpenJDK releases. While I appreciate that the
process has become easier with OpenJDK 8 vs the prior OpenJDK versions,
right now the build process for new releases, particularly critical
security updates, seems quite the mess.
For example:
To build OpenJDK 1.8u66, you have to use the jdk8u (JDK 8 Updates Master)
branch (doesn't make sense)
To build OpenJDK 1.8u60, you use the jdk8u60 release branch (makes sense)
To build OpenJDK 1.8u51, you use the jdk8u60-dev branch (doesn't make sense)
The lack of consistency among branches for different releases makes it
extremely hard to create a well defined build process for OpenJDK.
In addition the fact that the bug system is locked down makes it extremely
hard to report issues back upstream, such as the fact that the hgforest.sh
script doesn't correctly honor command arguments, meaning that it has to be
patched to get a consistent build of the downstream modules that get
checked out. The following patch fixes this rather significant problem.
As we rely heavily on being able to provide up to date, consistent, secure
OpenJDK builds to our customers, having the process to build new releases
be reliable is of significant importance. I imagine that is the case for
many others as well.
Thanks for your time and consideration,
Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
From dalibor.topic at oracle.com Thu Nov 12 14:53:18 2015
From: dalibor.topic at oracle.com (dalibor topic)
Date: Thu, 12 Nov 2015 15:53:18 +0100
Subject: Coherent release process
In-Reply-To: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]>
References: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]>
Message-ID: <5644A7DE.2020605@oracle.com>
On 12.11.2015 04:42, Quanah Gibson-Mount wrote:
> if/when the OpenJDK project may develop a more coherent release plan?
You can find the plans for JDK 9 at
http://openjdk.java.net/projects/jdk9/ . The plans for JDK 8 Updates are
linked off the Project page of the corresponding JDK 8 Updates Project
in the OpenJDK Community at http://openjdk.java.net/projects/jdk8u/ .
The corresponding Project's mailing list, jdk8u-dev, is the right place
to ask questions about JDK 8 Updates in OpenJDK. The JDK 8 Project has
completed its work with the JDK 8 GA a while ago, so this list is
largely dormant.
> The lack of consistency among branches for different releases makes
> it extremely hard to create a well defined build process for OpenJDK.
The separate Mercurial forests existed for the convenience of developing
multiple releases with a large number of changes and features in
parallel within a single OpenJDK Project (just as was the case for the
JDK 7 Updates Project, fwiw).
For reasons discussed back in July, the JDK 8 Updates Project in OpenJDK
no longer needs to do that. Accordingly, the jdk8u master and dev
forests are adequate for our current needs. Please see
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-July/003985.html
for details.
If for some reason you strive to create your own build process for JDK 8
Updates, I'd suggest subscribing at least to the jdk8u-dev, jdk9-dev and
build-dev mailing lists.
Instructions for checking out the code for the latest release developed
within the JDK 8 Updates Project in OpenJDK can be found on the
Project's web page. Please keep in mind that CPU releases like 8u51 are
not developed within OpenJDK Projects.
> In addition the fact that the bug system is locked down
Please consult the "Account Eligibility" section of
https://wiki.openjdk.java.net/display/general/JBS+Overview for the facts.
If you are not eligible for an account on JBS, because you're not an
OpenJDK developer with an adequate role, you may still file issues
through the web interface at bugs.java.com.
> The following patch fixes this
Please see http://openjdk.java.net/contribute/ for how to contribute to
OpenJDK Projects, and note in particular the requirements spelled out in
section 0.
Of particular note for the contribution flow to the JDK 8 Updates
Project is that changes to it will typically go through JDK 9 first.
So once your organization meets the requirements spelled out in the
guide above, I'd suggest adjusting, testing and sending your proposed
patch as plain text within an e-mail to the build-dev mailing list for
JDK 9 first. Once it has been reviewed and pushed there, then you can
follow up with a backport for the JDK 8 Updates Project. Details on the
backport process can be found at the JDK 8 Updates page linked above.
> As we rely heavily on being able to provide up to date, consistent,
> secure OpenJDK builds to our customers
Unfortunately, I don't see your organization listed at
http://www.oracle.com/technetwork/community/oca-486395.html so I'd like
to again refer you to the guide for contributing to OpenJDK linked above.
cheers,
dalibor topic
--
Dalibor Topic | Principal Product Manager
Phone: +494089091214 | Mobile: +491737185961
ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher
Oracle is committed to developing
practices and products that help protect the environment
From cdelunasaenz at yahoo.com.mx Thu Nov 12 15:18:44 2015
From: cdelunasaenz at yahoo.com.mx (Carlos de Luna Saenz)
Date: Thu, 12 Nov 2015 15:18:44 +0000 (UTC)
Subject: Coherent release process
In-Reply-To: <5644A7DE.2020605@oracle.com>
References: <5644A7DE.2020605@oracle.com>
Message-ID: <341172378.3868280.1447341524085.JavaMail.yahoo@mail.yahoo.com>
I'm sure this topic has arise sooner here... but PPAPI is being considered... lot of oraganizations relies on Java applets for key based authentication and is a very important deal...
If you can clear me on what's the future of applets fron open JDK perspective i will appreciate it.Greetings
De: dalibor topic
Para: jdk8-dev at openjdk.java.net
Enviado: Jueves, 12 de noviembre, 2015 8:53:18
Asunto: Re: Coherent release process
On 12.11.2015 04:42, Quanah Gibson-Mount wrote:
> if/when the OpenJDK project may develop a more coherent release plan?
You can find the plans for JDK 9 at
http://openjdk.java.net/projects/jdk9/ . The plans for JDK 8 Updates are
linked off the Project page of the corresponding JDK 8 Updates Project
in the OpenJDK Community at http://openjdk.java.net/projects/jdk8u/ .
The corresponding Project's mailing list, jdk8u-dev, is the right place
to ask questions about JDK 8 Updates in OpenJDK. The JDK 8 Project has
completed its work with the JDK 8 GA a while ago, so this list is
largely dormant.
> The lack of consistency among branches for different releases makes
> it extremely hard to create a well defined build process for OpenJDK.
The separate Mercurial forests existed for the convenience of developing
multiple releases with a large number of changes and features in
parallel within a single OpenJDK Project (just as was the case for the
JDK 7 Updates Project, fwiw).
For reasons discussed back in July, the JDK 8 Updates Project in OpenJDK
no longer needs to do that. Accordingly, the jdk8u master and dev
forests are adequate for our current needs. Please see
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-July/003985.html
for details.
If for some reason you strive to create your own build process for JDK 8
Updates, I'd suggest subscribing at least to the jdk8u-dev, jdk9-dev and
build-dev mailing lists.
Instructions for checking out the code for the latest release developed
within the JDK 8 Updates Project in OpenJDK can be found on the
Project's web page. Please keep in mind that CPU releases like 8u51 are
not developed within OpenJDK Projects.
> In addition the fact that the bug system is locked down
Please consult the "Account Eligibility" section of
https://wiki.openjdk.java.net/display/general/JBS+Overview for the facts.
If you are not eligible for an account on JBS, because you're not an
OpenJDK developer with an adequate role, you may still file issues
through the web interface at bugs.java.com.
> The following patch fixes this
Please see http://openjdk.java.net/contribute/ for how to contribute to
OpenJDK Projects, and note in particular the requirements spelled out in
section 0.
Of particular note for the contribution flow to the JDK 8 Updates
Project is that changes to it will typically go through JDK 9 first.
So once your organization meets the requirements spelled out in the
guide above, I'd suggest adjusting, testing and sending your proposed
patch as plain text within an e-mail to the build-dev mailing list for
JDK 9 first. Once it has been reviewed and pushed there, then you can
follow up with a backport for the JDK 8 Updates Project. Details on the
backport process can be found at the JDK 8 Updates page linked above.
> As we rely heavily on being able to provide up to date, consistent,
> secure OpenJDK builds to our customers
Unfortunately, I don't see your organization listed at
http://www.oracle.com/technetwork/community/oca-486395.html so I'd like
to again refer you to the guide for contributing to OpenJDK linked above.
cheers,
dalibor topic
--
Dalibor Topic | Principal Product Manager
Phone: +494089091214 | Mobile: +491737185961
ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher
Oracle is committed to developing
practices and products that help protect the environment
From dalibor.topic at oracle.com Thu Nov 12 18:21:45 2015
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Thu, 12 Nov 2015 19:21:45 +0100
Subject: Coherent release process
In-Reply-To: <341172378.3868280.1447341524085.JavaMail.yahoo@mail.yahoo.com>
References: <5644A7DE.2020605@oracle.com>
<341172378.3868280.1447341524085.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <5644D8B9.3010801@oracle.com>
On 11/12/15 4:18 PM, Carlos de Luna Saenz wrote:
> I'm sure this topic has arise sooner here... but PPAPI is being considered... lot of oraganizations relies on Java applets for key based authentication and is a very important deal...
> If you can clear me on what's the future of applets fron open JDK perspective i will appreciate it.Greetings
>From the mention of PPAPI I assume that this question is about a browser plugin. There is no implementation of a browser plugin in OpenJDK.
cheers,
dalibor topic
--
Oracle
Dalibor Topic | Principal Product Manager
Phone: +494089091214 | Mobile: +491737185961
Oracle Java Platform Group
ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher
Green Oracle Oracle is committed to developing practices and products that help protect the environment
From gnu.andrew at redhat.com Fri Nov 20 03:34:57 2015
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 19 Nov 2015 22:34:57 -0500 (EST)
Subject: Coherent release process
In-Reply-To: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]>
References: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]>
Message-ID: <447666547.12112509.1447990497599.JavaMail.zimbra@redhat.com>
[Adding in the 8u mailing list]
----- Original Message -----
> Hi,
>
> I was wondering if/when the OpenJDK project may develop a more coherent
> release plan? Right now, there seems to be no consistent strategy, which
> makes it very difficult for downstream consumers of OpenJDK to be able to
> reliably build out new OpenJDK releases. While I appreciate that the
> process has become easier with OpenJDK 8 vs the prior OpenJDK versions,
> right now the build process for new releases, particularly critical
> security updates, seems quite the mess.
+1. I've said pretty much the same before and it's only got worse of late.
The number of people I have to explain it to, even people who actively work
on OpenJDK on a daily basis, suggests it's far from obvious. It's nice to
know I'm not the only one who feels this way.
>
> For example:
>
> To build OpenJDK 1.8u66, you have to use the jdk8u (JDK 8 Updates Master)
> branch (doesn't make sense)
> To build OpenJDK 1.8u60, you use the jdk8u60 release branch (makes sense)
> To build OpenJDK 1.8u51, you use the jdk8u60-dev branch (doesn't make sense)
>
Actually, that won't get you u66 unless you explicitly check out a tag.
The current tip of 8u is currently receiving fixes people are pushing for u76,
which I believe is due to be released next April, at the same time as the u75
security update, which will be based on u72.
As far as I've been able to grasp, this is the current 8u schedule:
October 2015: u65 (security update based on u60) & u66 (feature release)
January 2016: u71 (security update based on u66) & u72 (feature release)
April 2016: u75 (security update based on u72) & u76 (feature release)
July 2016: u81 (security update based on u76) & u82 (feature release)
You should be able to get all versions from the 8u tree by checking out
appropriate tags. Only 8u65 onwards will be up to date with the latest
security fixes.
> The lack of consistency among branches for different releases makes it
> extremely hard to create a well defined build process for OpenJDK.
Moreover, the recent changes, as I've mentioned before, also make it
virtually impossible to test something like u72 before it is released.
What I witnessed with u66 was the first few builds being pushed to the
8u tree, but later builds did not appear until u66 was released in late
October. When I raised this before, it was pointed out that the build
could be reconstructed by finding bugs in the bug database that had been
tagged as added to the release and backporting them to a checkout of
the latest u66 tag myself [0]. Not only is this incredibly time consuming
and error prone, but there is no guarantee that the result is the same
as what Oracle are testing. I really don't think the OpenJDK project as
a whole should suffer because Oracle change their internal processes.
>
> In addition the fact that the bug system is locked down makes it extremely
> hard to report issues back upstream, such as the fact that the hgforest.sh
> script doesn't correctly honor command arguments, meaning that it has to be
> patched to get a consistent build of the downstream modules that get
> checked out. The following patch fixes this rather significant problem.
>
>
>
> As we rely heavily on being able to provide up to date, consistent, secure
> OpenJDK builds to our customers, having the process to build new releases
> be reliable is of significant importance. I imagine that is the case for
> many others as well.
Another problem I've also observed. I'm happy for you to ping me if you have
a patch and need a bug opening (I've done this for colleagues at Red Hat),
but as Dalibor mentions in response, the OCA needs to be sorted first. There's
not much point opening a bug with a patch if the patch can't be committed for
legal reasons.
>
> Thanks for your time and consideration,
> Quanah
>
> --
>
> Quanah Gibson-Mount
> Platform Architect
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
[0] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-September/004212.html
Thanks,
--
Andrew :)
Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
From gnu.andrew at redhat.com Fri Nov 20 03:39:35 2015
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 19 Nov 2015 22:39:35 -0500 (EST)
Subject: Coherent release process
In-Reply-To: <5644A7DE.2020605@oracle.com>
References: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]>
<5644A7DE.2020605@oracle.com>
Message-ID: <498111152.12112954.1447990775779.JavaMail.zimbra@redhat.com>
----- Original Message -----
> On 12.11.2015 04:42, Quanah Gibson-Mount wrote:
> > if/when the OpenJDK project may develop a more coherent release plan?
>
> You can find the plans for JDK 9 at
> http://openjdk.java.net/projects/jdk9/ . The plans for JDK 8 Updates are
> linked off the Project page of the corresponding JDK 8 Updates Project
> in the OpenJDK Community at http://openjdk.java.net/projects/jdk8u/ .
>
> The corresponding Project's mailing list, jdk8u-dev, is the right place
> to ask questions about JDK 8 Updates in OpenJDK. The JDK 8 Project has
> completed its work with the JDK 8 GA a while ago, so this list is
> largely dormant.
>
Is there a good reason for this practice? Having seen this happen with
both 7/7u and 8/8u mailing lists, it would seem to make sense to keep
one mailing list instead when 9 goes GA, to avoid this confusion.
It's things like this that make OpenJDK confusing to new users and
I don't see the necessity for it myself.
Thanks,
--
Andrew :)
Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
From quanah at zimbra.com Fri Nov 20 03:45:51 2015
From: quanah at zimbra.com (Quanah Gibson-Mount)
Date: Thu, 19 Nov 2015 19:45:51 -0800
Subject: Coherent release process
In-Reply-To: <447666547.12112509.1447990497599.JavaMail.zimbra@redhat.com>
References: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]>
<447666547.12112509.1447990497599.JavaMail.zimbra@redhat.com>
Message-ID:
--On Thursday, November 19, 2015 10:34 PM -0500 Andrew Hughes
wrote:
> [Adding in the 8u mailing list]
>
> ----- Original Message -----
>> Hi,
Hi Andrew,
Thanks for the follow up!
> Actually, that won't get you u66 unless you explicitly check out a tag.
> The current tip of 8u is currently receiving fixes people are pushing for
> u76, which I believe is due to be released next April, at the same time
> as the u75 security update, which will be based on u72.
Yes, I use a tag for building. However, that process is completely
unreliable UNLESS you use my patch, because the tag is not passed down when
pulling out the sub modules, which means you get mismatched code. I.e.,
without my patch, you cannot build a consistent OpenJDK release against a
specific tag.
>>
>>
>> As we rely heavily on being able to provide up to date, consistent,
>> secure OpenJDK builds to our customers, having the process to build new
>> releases be reliable is of significant importance. I imagine that is
>> the case for many others as well.
>
> Another problem I've also observed. I'm happy for you to ping me if you
> have a patch and need a bug opening (I've done this for colleagues at Red
> Hat), but as Dalibor mentions in response, the OCA needs to be sorted
> first. There's not much point opening a bug with a patch if the patch
> can't be committed for legal reasons.
I can't see why it'd be a problem to have the patch committed. It's
literally modifying hgforest.sh to include the ${command_args} command line
options that were originally passed get_source.sh. Again, without this
patch, there is literally no way to build OpenJDK where all portions of the
checkout from mercurial are fixed to a given tag.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
From david.holmes at oracle.com Fri Nov 20 03:51:51 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Nov 2015 13:51:51 +1000
Subject: Coherent release process
In-Reply-To:
References: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]>
<447666547.12112509.1447990497599.JavaMail.zimbra@redhat.com>
Message-ID: <564E98D7.9050504@oracle.com>
Trivial patches can be accepted without the provider being an OCA
signatory. However the patch must be provided using OpenJDK technology
so it can't be taken from an external website, but if small enough
should be included inline in an email message.
Thanks,
David
On 20/11/2015 1:45 PM, Quanah Gibson-Mount wrote:
>
> --On Thursday, November 19, 2015 10:34 PM -0500 Andrew Hughes
> wrote:
>
>> [Adding in the 8u mailing list]
>>
>> ----- Original Message -----
>>> Hi,
>
> Hi Andrew,
>
> Thanks for the follow up!
>
>
>> Actually, that won't get you u66 unless you explicitly check out a tag.
>> The current tip of 8u is currently receiving fixes people are pushing for
>> u76, which I believe is due to be released next April, at the same time
>> as the u75 security update, which will be based on u72.
>
> Yes, I use a tag for building. However, that process is completely
> unreliable UNLESS you use my patch, because the tag is not passed down
> when pulling out the sub modules, which means you get mismatched code.
> I.e., without my patch, you cannot build a consistent OpenJDK release
> against a specific tag.
>
>>>
>>>
>>> As we rely heavily on being able to provide up to date, consistent,
>>> secure OpenJDK builds to our customers, having the process to build new
>>> releases be reliable is of significant importance. I imagine that is
>>> the case for many others as well.
>>
>> Another problem I've also observed. I'm happy for you to ping me if you
>> have a patch and need a bug opening (I've done this for colleagues at Red
>> Hat), but as Dalibor mentions in response, the OCA needs to be sorted
>> first. There's not much point opening a bug with a patch if the patch
>> can't be committed for legal reasons.
>
> I can't see why it'd be a problem to have the patch committed. It's
> literally modifying hgforest.sh to include the ${command_args} command
> line options that were originally passed get_source.sh. Again, without
> this patch, there is literally no way to build OpenJDK where all
> portions of the checkout from mercurial are fixed to a given tag.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Platform Architect
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
From quanah at zimbra.com Fri Nov 20 03:56:24 2015
From: quanah at zimbra.com (Quanah Gibson-Mount)
Date: Thu, 19 Nov 2015 19:56:24 -0800
Subject: Coherent release process
In-Reply-To: <564E98D7.9050504@oracle.com>
References: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]>
<447666547.12112509.1447990497599.JavaMail.zimbra@redhat.com>
<564E98D7.9050504@oracle.com>
Message-ID: <371DE40DAE08D273FAA2D3CD@[192.168.1.9]>
--On Friday, November 20, 2015 1:51 PM +1000 David Holmes
wrote:
> Trivial patches can be accepted without the provider being an OCA
> signatory. However the patch must be provided using OpenJDK technology so
> it can't be taken from an external website, but if small enough should be
> included inline in an email message.
--- jdk8u60/common/bin/hgforest.sh.orig 2015-08-10 16:29:42.271352215 +0000
+++ jdk8u60/common/bin/hgforest.sh 2015-08-10 16:36:53.427337849 +0000
@@ -334,8 +334,8 @@
done
fi
# run the clone command.
- echo "hg${global_opts} clone ${clone_newrepo} ${i}" >
${status_output}
- (PYTHONUNBUFFERED=true hg${global_opts} clone ${clone_newrepo}
${i}; echo "$?" > ${tmp}/${repopidfile}.pid.rc ) 2>&1 &
+ echo "hg${global_opts} clone ${command_args} ${clone_newrepo}
${i}" > ${status_output}
+ (PYTHONUNBUFFERED=true hg${global_opts} clone ${command_args}
${clone_newrepo} ${i}; echo "$?" > ${tmp}/${repopidfile}.pid.rc ) 2>&1 &
else
# run the command.
echo "cd ${i} && hg${global_opts} ${command} ${command_args}" >
${status_output}
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
From souvik1997 at gmail.com Tue Nov 24 06:11:37 2015
From: souvik1997 at gmail.com (Souvik Banerjee)
Date: Tue, 24 Nov 2015 00:11:37 -0600
Subject: Handling file:/ URLs with queries on Windows
References:
Message-ID: <7B18FD2E-C512-451A-9240-F75A1623E4EB@gmail.com>
On Windows, opening file:/ URLs with question marks in their name does not work as expected. On Unix-like operating systems, a URL like "file:///var/www/index.html?search=query" would open the file "/var/www/index.html". But on Windows the equivalent URL (using drive letters instead) would open "index.html?search=query" which does not exist. I expect "index.html" to be opened on Windows.
I think I have traced this issue to the following file:
https://github.com/openjdk-mirror/jdk7u-jdk/blob/f4d80957e89a19a29bb9f9807d2a28351ed7f7df/src/windows/classes/sun/net/www/protocol/file/Handler.java
On line 79 the getFile() method is called and is decoded with ParseUtil.decode(). According to line 808 of src/share/classes/java/net/URL.java getFile() returns the concatenation of getURL() and getQuery().
However, in src/solaris/classes/sun/net/www/protocol/file/Handler.java at line 80, getPath() is used instead (which removes the query part of the URL). I think getPath() should be used in the Windows file handler as well.
I tried checking the Java Bug Database to see if this issue had been reported, but I could not find any similar issues. Please let me know if this is actually what is supposed to happen.
Souvik Banerjee
From dalibor.topic at oracle.com Fri Nov 27 11:59:47 2015
From: dalibor.topic at oracle.com (dalibor topic)
Date: Fri, 27 Nov 2015 12:59:47 +0100
Subject: Coherent release process
In-Reply-To: <498111152.12112954.1447990775779.JavaMail.zimbra@redhat.com>
References: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]>
<5644A7DE.2020605@oracle.com>
<498111152.12112954.1447990775779.JavaMail.zimbra@redhat.com>
Message-ID: <565845B3.7080802@oracle.com>
On 20.11.2015 04:39, Andrew Hughes wrote:
>> The corresponding Project's mailing list, jdk8u-dev, is the right place
>> to ask questions about JDK 8 Updates in OpenJDK. The JDK 8 Project has
>> completed its work with the JDK 8 GA a while ago, so this list is
>> largely dormant.
>>
>
> Is there a good reason for this practice?
Yes.
A JDK Release Project like JDK 8 is very different from a JDK 8 Updates
Project, even though one provides the source code necessary to seed the
other.
As a trivial example of the differences, a JDK Release Project works
towards a single release, and then it's done. A JDK Updates Project
tends to work on multiple releases in parallel, provided at a higher
frequency. Accordingly, the processes, the development life cycle, etc.
are quite different. It's much simpler to start from a clean slate in a
new Project, then to retrofit an existing one for a new purpose.
> Having seen this happen with
> both 7/7u and 8/8u mailing lists, it would seem to make sense to keep
> one mailing list instead when 9 goes GA, to avoid this confusion.
No.
Please see http://openjdk.java.net/projects/ : "A Project may have web
content, one or more file repositories, and one or more mailing lists"
Mailing lists are Project-specific. Once a Project finishes its work,
its mailing list(s) eventually gets dormant and archived, rather than
reused for other Projects. See
http://mail.openjdk.java.net/pipermail/coin-dev/2015-April/003487.html
for an example.
cheers,
dalibor topic
--
Dalibor Topic | Principal Product Manager
Phone: +494089091214 | Mobile: +491737185961
ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher
Oracle is committed to developing
practices and products that help protect the environment