In addition to Alan's point, but not in any way specifically about this fix,
I'd like to ask why backport requests are unaccompanied by any kind
of risk assessment and justification ? Do we lack a guideline on this ?
Is the release manager expected to be able to deduce the risk etc ?
'Stabilisation' fixes, Escalated bugs, support for new versions of
platforms,
key features that can't wait for JDK 8 are all potential reasons, and its
really not hard to provide such reasons in the backport request.
As Ihe "N" in 7uN increases, the number of fixes going in needs to decrease,
and the bar for the fixes, needs to be increased. The whole update process
needs to be move into something more like a 'rampdown' phase.
All my opinion of course, and I'm sure there are other opinions out there.
-phil.
On 9/17/12 2:06 AM, Alan Bateman wrote:
For the record, I have concerns about back-porting this to 7u. The
reason is that switching to getnameinfo and getaddrinfo can result in
subtle behavioral changes that cause problems for applications and
developers. A recent one in this area was:
http://bugs.sun.com/view_bug.do?bug_id=7166687
where the Mac port changed 7u4 to use getnameinfo, it was switched
back in 7u5 to restore previous behavior. I realize the changes you
are looking to back port are for the IPv4 case and maybe there are
people running with IPv6 disabled but I think we need to fully
understand any behavior changes before this is considered for a 7u
release.
-Alan.
On 17/09/2012 09:14, Shi Jun Zhang wrote:
Hi all,
I'd like to request for approval to push the following change into 7u10.
Changeset in jdk8
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81987765cb81
Webrev
http://cr.openjdk.java.net/~zhangshj/jdk7u/7112670/webrev.00/
Reviewed by chegar, alanb, mduigou, ngmr
Review thread
http://mail.openjdk.java.net/pipermail/net-dev/2011-November/003702.html
