[IMMINENT RELEASE] 1.10.1

Thu Mar 24 09:27:39 PDT 2011

On 15:45 Thu 24 Mar     , Matthias Klose wrote:
> On 24.03.2011 15:23, Dr Andrew John Hughes wrote:
> > On 13:14 Thu 24 Mar     , Matthias Klose wrote:
> >> On 23.03.2011 17:08, Dr Andrew John Hughes wrote:
> >>> I'd like to release 1.10.1 on Wednesday the 30th of March at 14h00 UTC.
> >>
> >> We do want to have some time for testing. Not all proposed changes are found in
> >> the branch yet, so I really would like to see these changes in the branch, and
> >> *then* have a week for testing. Assuming that the changes are checked in today
> >> or tomorrow, please don't release before Mar 31 or Apr 1 (no April joke).
> >>
> > 
> > Ok, let's make it the same time on Monday the 4th of April.  I'm not around on
> > the 1st, and even if there is a release on the 31st there may be issues.
> > 
> >>> other additions?
> >>
> >> yes, testing, and documentation of testing.  With the latest security fixes and
> >> the non-default hotspot came some regressions.  If not fixed, these should be at
> >> least documented.
> > 
> > Well, the branch is there to test.
> 
> then please check in changes which are targeted for the release.

I have pushed the hs20 bump now it has been approved.  I can't do that before approval,
but the patch has been on HEAD a couple of days and thus tested by the build bots.

> 
> > If things need to be documented, we can review
> > patches for README or INSTALL as suitable.
> 
> The master overview should be in some place which can be edited after the
> release too, e.g. the wiki.  README and INSTALL should just point to it.
> 

No, the README and INSTALL can (and do) reference the wiki but they should be
self-contained, so they can be referenced offline, and pertain to the particular release.

You are more than welcome to add material to the wiki.  If you don't have access, ask
Mark Wielaard.

> > Can you elaborate on these regressions?  I thought they'd all been resolved before
> > the release of 1.10.
> 
> jdk tests hang with hotspot hs20, at least with zero/shark builds. I would be
> interested if these hang on x86 on other platforms too.

Not that I've heard, but I don't run them.  There have always been some that have been
broken.

What tests are we talking about?  Are they actually useful?

> 
> >> If testing reveals regressions, do we consider these as release blockers, and if
> >> yes, for which configurations?
> > 
> > Has to be on a case-by-case basis.
> 
> So who makes this decision?
> 

I would hope all interested parties would come to a consensus.

The reality is that the vast majority of IcedTea end users will be on x86 or x86_64
platforms using HotSpot, so my general feeling is that a release should not be
blocked for this platform due to issues on the minority Zero/Shark/etc. platforms.

I think we can also all agree that security fixes should go out directly if they
work on the main platforms.

As to tests failing, I think the first thing to ascertain is that it is not the
test that is at fault or an intermittent issue.  The majority of test issues I've
seen have been broken tests.

There's also only a point in blocking a release due to a regression if someone
is working on a fix.  I ended up having to fix Shark for 1.10 because no-one else
stepped up to do it.  I'm not going to be doing that again.

> >> For the documentation of the tests, maybe have a wiki page for each release
> >> branch with a matrix architecture/VM, and the cells mentioning the last version
> >> tested on this branch.  Then at least it's visible which configurations did see
> >> some attention.
> >>
> >> Which VM's to test?
> >>
> >>  - default hotspot on x86
> >>
> >> should be required for x86 and x86_64, regressions should be release blockers.
> >>
> >>  - zero on x86? ARM? powerpc?
> >>  - shark?
> >>  - optional hotspot on x86?
> >>
> >> I assume these could be tested without too much trouble, and even running the
> >> jdk tests for a subset of these should be possible.
> >>
> >>  - JamVM?
> >>  - CACAO?
> >>
> >> Optional, but would be good to know that a certain configuration is tested.
> >>
> > 
> > Well, a lot of this depends on what hardware people have available, though mjw's
> > builders can help with that.  For instance, I only regularly build on x86_64 as
> > that's the main hardware I have available.  I can build on ppc if there's a need.
> > I simply don't have x86 hardware any more.
> 
> Lack of x86 hardware is not an argument. Depending on the distribution you use
> you should be able to build x86 on x86_64 out of the box, or you could use a chroot.
> 

Personally, I'm not going to waste time and disk space maintaining an
entire other platform and doing additional builds on it.  This is what
the buildbots and distro builds are for.

> > I usually just do a default build
> > (configure plus zip locations) with an additional alt-HotSpot build if the change
> > affects HotSpot code.
> > 
> > For Zero, Shark, CACAO, JamVM, and the ARM port, I rely on people who care about
> > these to maintain them.  For major releases, I try to build them, and AFAIK they
> > were all working for 1.10.  For CACAO and JamVM, Xerxes certainly seems to have 
> > given them a lot of love and I trust him on this.  I have no clue what's going
> > on with the ARM port and, as I've posted twice before, it will be dropped with
> > 1.11 unless the situation changes.
> 
> I'll send a followup until end of May. For now, you could just disable it
> without dropping it.
> 

It already is disabled.  As previously mentioned (with no response):

http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-March/012556.html

and it seems Xerxes just pointed to the exact changeset on IRC (thanks!):

http://icedtea.classpath.org/hg/icedtea6/rev/18fbca177289

I plan to get HotSpot 20 into OpenJDK6 over the next couple of weeks
(depending on work on IcedTea7).  If nothing changes when b23 is
released with this in, there will be no point having the ARM port as
it will be unbuildable.  According to Gary, it's already broken in 1.10
due to API changes, and I don't see a point in shipping another major
release with dead code in it.

The 1.11 release is tentatively scheduled for late June after the next
security release, so there is time until then for you or someone else
to step up and maintain it.

>   Matthias

-- 
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