Early access builds

[Mark Wielaard]

Hi Kelly,

> I'll stick my neck out a little here...
> If I could somehow make some purely OpenJDK7 built zip bundles available,
> with no promises on any test results and with no support.
> Could we start with that? Does that help or make things worse.
> I want to fix this but am only one person, or half a person sometimes,
> so help me out here...
> Can you provide specifics on what you would expect of any openjdk7 builds?
>
> Can we start a separate email thread on this?

Thanks and good idea.
So, lets back up a little more, so we really start this thread from
scratch and make sure we are on the same page. You said earlier...

> And I don't understand the problem, we have never have published
> 'open' builds. We could I suppose, and probably should, but we don't.
> To a large degree we didn't think it made any sense because the Distros
> built their own. So we let people know when the proprietary builds were
> available because some people wanted them.
> Then other people gets all bent out of shape about it. :^(

And to be clear I am the "other people" getting all bent out of shape
here :) So, why is that? And what is wrong with these "closed" builds
that do get published?

The OpenJDK project has rules, under http://openjdk.java.net/legal/ on
how to produce fully open and partially closed derivatives. If you want
a fully open build, you get the sources under the GPL, some additional
permissions under the Classpath Exception to combine with other free
software stuff and off you go. This is basically what IcedTea and the
various GNU/Linux distributions do now. Follow the letter and spirit of
the GPL and everybody is happy.

If you want to produce a (partially) closed build you are also allowed
to do that. For historical reasons there are sadly some proprietary
binary blobs that cannot be distributed under free terms, but you do get
permission to distribute these together with the rest (provided you
follow the terms of the GPL for that of course) and get an additional
special Assembly Exception to combine with these Designated Exception
Modules to form a larger work for which the GPL only applies to the free
and open parts.

Now, various OpenJDK projects want to do "early access" releases.
Sometimes even for stuff that isn't in the main repo yet. Because they
like working with the larger community and provide them with easily
runnable bits (these are so early they wouldn't normally be packaged by
any distribution). So they publish these build downloads on their
OpenJDK project pages and/or post to the mailinglist inviting people to
work together and test the bits in progress.

Now here is were it becomes awkward. These early access builds aren't
published as open builds, but they are also not published as (partially)
closed builds according to the OpenJDK legal rules. No, they are
published under a completely different very draconian proprietary
license that says you may not you even try to study how this works, try
to figure out what the underlying source code is, use it for any purpose
except for telling Sun, and only Sun! what might be wrong with these
builds, and if you don't treat anything you might learn from these
builds as proprietary confidential information not to be shared with
anybody you will cause Sun irreparable damage for which recovery of
money damages would be inadequate...

Hohum. That isn't very nice.

Sidenote (and the reason I send the original email): It certainly made
me pause and decide not to use the nio2 early access builds to try and
figure out what was wrong with the nio2 tests included in IcedTea or
give any feedback. Damn, I thought, if this is how it has to be, then no
cooperation! Luckily, Alan Bateman stands way above all this little
bickering, so he contacted me, we went over all the failures I saw in my
build, and he personally explained each and every one away. Go Alan!

I am under the impression this is an old relic from before the OpenJDK
project, the adoption of the GPL and before the goal was to come
together with the community at large to create a completely free and
open java implementation. I wouldn't have balked (so much) if I had
found the binaries produced as partial closed binaries. I do understand
not everybody is convinced yet the free replacements are better, or at
least as good as the old proprietary plugs. So if an graphics oriented
OpenJDK project published partially closed builds as early access, well,
I don't like it, but I can see why. But non-graphics related OpenJDK
projects not publishing their early access builds under the fully free
terms is rather quaint. And having them publish such builds under terms
that basically forbid any cooperation between community members because
they are totally Sun proprietary and confidential is completely nuts.
IMHO of course.

So, I think that what we really need is rules for OpenJDK projects that
want to publish Early Access build artifacts. IMHO if they do, they
should do that in accordance to the rules that everybody needs to
follow, which are spelled out at http://openjdk.java.net/legal/
That is the only fair thing to do.

Cheers,

Mark

[kelly.ohair]

Mark Wielaard wrote:
> Hi Kelly,
[snip]
> Sidenote (and the reason I send the original email): It certainly made
> me pause and decide not to use the nio2 early access builds to try and
> figure out what was wrong with the nio2 tests included in IcedTea or
> give any feedback. Damn, I thought, if this is how it has to be, then no
> cooperation! Luckily, Alan Bateman stands way above all this little
> bickering, so he contacted me, we went over all the failures I saw in my
> build, and he personally explained each and every one away. Go Alan!

Yes, Go Alan. ;^)

[snip]

I understand.

>
> So, I think that what we really need is rules for OpenJDK projects that
> want to publish Early Access build artifacts. IMHO if they do, they
> should do that in accordance to the rules that everybody needs to
> follow, which are spelled out at http://openjdk.java.net/legal/
> That is the only fair thing to do.

I have no disagreement here. I think we can fix this. Probably about time
anyway.

And to be clear, in my opinion, any 'open' build published should be one
built without the binary plugs, I would very much like for them to die,
be buried, and be forgotten.

Effectively what I'm thinking is a kind of cleanroom build of an openjdk
forest, using Fedora 9 X86 32bit, and OpenSolaris X86 32bit to start.
I'll create a simple self-extracting tarball installer (no rpm/deb/ips packages),
and publish them in a public openjdk area.
No testing to start, but adding testing with published results could
be done by just about anyone.
If I do this right, we can in theory point at any openjdk project forest
and provide the same build service for any project.

Granted, I think anyone in the community could probably do the same
thing, and I'm happy to step aside for someone else to do it, whatever,
but let's get something done here.

Assuming I'm not fired or sent to Iraq for sticking my neck out on this,
does this sound like a reasonable start?

-kto

[Martin Buchholz-3]

If Sun provides a place with enough disk space and write access,
I offer to make available the openjdk6 and openjdk7 binaries I have built
for linux-{i586,amd64}{,-fastdebug}.  100GB, give or take an order of
magnitude.
Built for Ubuntu dapper, but has a good chance of working on Red Hat
systems.

Martin

On Sun, May 31, 2009 at 14:20, Kelly O'Hair <Kelly.Ohair@...> wrote:

>
> Mark Wielaard wrote:
>
>> Hi Kelly,
>>
> [snip]
>
>> Sidenote (and the reason I send the original email): It certainly made
>> me pause and decide not to use the nio2 early access builds to try and
>> figure out what was wrong with the nio2 tests included in IcedTea or
>> give any feedback. Damn, I thought, if this is how it has to be, then no
>> cooperation! Luckily, Alan Bateman stands way above all this little
>> bickering, so he contacted me, we went over all the failures I saw in my
>> build, and he personally explained each and every one away. Go Alan!
>>
>
> Yes, Go Alan. ;^)
>
> [snip]
>
> I understand.
>
>
>> So, I think that what we really need is rules for OpenJDK projects that
>> want to publish Early Access build artifacts. IMHO if they do, they
>> should do that in accordance to the rules that everybody needs to
>> follow, which are spelled out at http://openjdk.java.net/legal/
>> That is the only fair thing to do.
>>
>
> I have no disagreement here. I think we can fix this. Probably about time
> anyway.
>
> And to be clear, in my opinion, any 'open' build published should be one
> built without the binary plugs, I would very much like for them to die,
> be buried, and be forgotten.
>
> Effectively what I'm thinking is a kind of cleanroom build of an openjdk
> forest, using Fedora 9 X86 32bit, and OpenSolaris X86 32bit to start.
> I'll create a simple self-extracting tarball installer (no rpm/deb/ips
> packages),
> and publish them in a public openjdk area.
> No testing to start, but adding testing with published results could
> be done by just about anyone.
> If I do this right, we can in theory point at any openjdk project forest
> and provide the same build service for any project.
>
> Granted, I think anyone in the community could probably do the same
> thing, and I'm happy to step aside for someone else to do it, whatever,
> but let's get something done here.
>
> Assuming I'm not fired or sent to Iraq for sticking my neck out on this,
> does this sound like a reasonable start?
>
> -kto
>

[Jonathan Gibbons]

The cr.openjdk.java.net space is good, but it is user-oriented (file  
space is addressed by username), and the overall name implies it is  
for code reviews (only?).

It would be good if Sun would provide more project-oriented file  
space, such that each project gets an amount of filespace, for any/all  
project related info -- which could include code reviews, builds, test-
reports, and so on.

-- Jon


On May 31, 2009, at 6:24 PM, Martin Buchholz wrote:

> If Sun provides a place with enough disk space and write access,
> I offer to make available the openjdk6 and openjdk7 binaries I have  
> built
> for linux-{i586,amd64}{,-fastdebug}.  100GB, give or take an order of
> magnitude.
> Built for Ubuntu dapper, but has a good chance of working on Red Hat
> systems.
>
> Martin
>
> On Sun, May 31, 2009 at 14:20, Kelly O'Hair <Kelly.Ohair@...>  
> wrote:
>
>>
>> Mark Wielaard wrote:
>>
>>> Hi Kelly,
>>>
>> [snip]
>>
>>> Sidenote (and the reason I send the original email): It certainly  
>>> made
>>> me pause and decide not to use the nio2 early access builds to try  
>>> and
>>> figure out what was wrong with the nio2 tests included in IcedTea or
>>> give any feedback. Damn, I thought, if this is how it has to be,  
>>> then no
>>> cooperation! Luckily, Alan Bateman stands way above all this little
>>> bickering, so he contacted me, we went over all the failures I saw  
>>> in my
>>> build, and he personally explained each and every one away. Go Alan!
>>>
>>
>> Yes, Go Alan. ;^)
>>
>> [snip]
>>
>> I understand.
>>
>>
>>> So, I think that what we really need is rules for OpenJDK projects  
>>> that
>>> want to publish Early Access build artifacts. IMHO if they do, they
>>> should do that in accordance to the rules that everybody needs to
>>> follow, which are spelled out at http://openjdk.java.net/legal/
>>> That is the only fair thing to do.
>>>
>>
>> I have no disagreement here. I think we can fix this. Probably  
>> about time
>> anyway.
>>
>> And to be clear, in my opinion, any 'open' build published should  
>> be one
>> built without the binary plugs, I would very much like for them to  
>> die,
>> be buried, and be forgotten.
>>
>> Effectively what I'm thinking is a kind of cleanroom build of an  
>> openjdk
>> forest, using Fedora 9 X86 32bit, and OpenSolaris X86 32bit to start.
>> I'll create a simple self-extracting tarball installer (no rpm/deb/
>> ips
>> packages),
>> and publish them in a public openjdk area.
>> No testing to start, but adding testing with published results could
>> be done by just about anyone.
>> If I do this right, we can in theory point at any openjdk project  
>> forest
>> and provide the same build service for any project.
>>
>> Granted, I think anyone in the community could probably do the same
>> thing, and I'm happy to step aside for someone else to do it,  
>> whatever,
>> but let's get something done here.
>>
>> Assuming I'm not fired or sent to Iraq for sticking my neck out on  
>> this,
>> does this sound like a reasonable start?
>>
>> -kto
>>

[Mark Wielaard]

On Sun, 2009-05-31 at 14:20 -0700, Kelly O'Hair wrote:
> I have no disagreement here. I think we can fix this. Probably about time
> anyway.
>
> And to be clear, in my opinion, any 'open' build published should be one
> built without the binary plugs, I would very much like for them to die,
> be buried, and be forgotten.

:) !

> Effectively what I'm thinking is a kind of cleanroom build of an openjdk
> forest, using Fedora 9 X86 32bit, and OpenSolaris X86 32bit to start.
> I'll create a simple self-extracting tarball installer (no rpm/deb/ips packages),
> and publish them in a public openjdk area.
> No testing to start, but adding testing with published results could
> be done by just about anyone.
> If I do this right, we can in theory point at any openjdk project forest
> and provide the same build service for any project.
>
> Granted, I think anyone in the community could probably do the same
> thing, and I'm happy to step aside for someone else to do it, whatever,
> but let's get something done here.
>
> Assuming I'm not fired or sent to Iraq for sticking my neck out on this,
> does this sound like a reasonable start?

That sounds like a wonderful start!

Thanks,

Mark

[tim.bell]

Jonathan Gibbons wrote:

> The cr.openjdk.java.net space is good, but it is user-oriented (file
> space is addressed by username), and the overall name implies it is for
> code reviews (only?).

Webrev and code reviews was the primary intent when we got it set
up.  As folks have discovered, it can be used to share anything
related to OpenJDK - build logs, documents, html, odd bits of code,
and yes, even JDK builds.


Martin Buchholz wrote:

> If Sun provides a place with enough disk space and write access,
> I offer to make available the openjdk6 and openjdk7 binaries I have built
> for linux-{i586,amd64}{,-fastdebug}.  100GB, give or take an order of
> magnitude.
> Built for Ubuntu dapper, but has a good chance of working on Red Hat
> systems.

You could use cr.ojn for that today.  The current ZFS pool is 237G with
3.3G in use.

Hopefully after JavaOne we can get back to this topic.  If we should
happen to meet up at the show this week I'd be glad to talk to you
about it.


Tim

[Mark Wielaard]

On Mon, 2009-06-01 at 05:55 +0200, Mark Wielaard wrote:

> On Sun, 2009-05-31 at 14:20 -0700, Kelly O'Hair wrote:
> > Effectively what I'm thinking is a kind of cleanroom build of an openjdk
> > forest, using Fedora 9 X86 32bit, and OpenSolaris X86 32bit to start.
> > I'll create a simple self-extracting tarball installer (no rpm/deb/ips packages),
> > and publish them in a public openjdk area.
> > No testing to start, but adding testing with published results could
> > be done by just about anyone.
> > If I do this right, we can in theory point at any openjdk project forest
> > and provide the same build service for any project.
>
> That sounds like a wonderful start!

So I hacked together a quick script this weekend to do this for the
IcedTea repos (attached below). It has been running for a couple of days
now. It isn't the most shiny solution. But I wanted something that just
worked for now. In the future we can think about extending it with fancy
frontends (maybe hudson integration to show jtreg results). For now it
just sits there looping through the repositories checking every 15
minutes whether there have been updates (this should of course be
triggered by a commit hook some day) and then does an autogen.sh &&
configure && make && make check reporting any build failures or changes
in test results it finds on the way (it reports them to everybody that
made a change since it last checked, if that gets annoying please yell
and we change it to only report to the mailinglist). Then it dumps the
build, sources and test results (including all .jtr files so you can
easily compare) at:

http://icedtea.classpath.org/builds/

Hope that is useful and can be extended to other repositories.

It currently only has space for one build per repository. And sadly has
to dump the documentation and debuginfo for now to preserve space. The
build is done in a Debian Lenny i686 chroot environment. Which should
produce binaries that run on most x86 GNU/Linux systems (Debian Lenny
was chosen since it has both a pretty old glibc, but also a new enough
gcj to bootstrap everything out of the box - well ok, and because the
host was already running a x86_64 Debian etch variant, so setting up a
lenny i686 chroot was pretty easy.).

Cheers,

Mark

[Mark Wielaard]

On Wed, 2009-06-10 at 09:52 +0200, Mark Wielaard wrote:

> On Mon, 2009-06-01 at 05:55 +0200, Mark Wielaard wrote:
> > On Sun, 2009-05-31 at 14:20 -0700, Kelly O'Hair wrote:
> > > Effectively what I'm thinking is a kind of cleanroom build of an openjdk
> > > forest, using Fedora 9 X86 32bit, and OpenSolaris X86 32bit to start.
> > > I'll create a simple self-extracting tarball installer (no rpm/deb/ips packages),
> > > and publish them in a public openjdk area.
> > > No testing to start, but adding testing with published results could
> > > be done by just about anyone.
> > > If I do this right, we can in theory point at any openjdk project forest
> > > and provide the same build service for any project.
> >
> > That sounds like a wonderful start!
>
> So I hacked together a quick script this weekend to do this for the
> IcedTea repos (attached below). It has been running for a couple of days
> now. It isn't the most shiny solution. But I wanted something that just
> worked for now. In the future we can think about extending it with fancy
> frontends (maybe hudson integration to show jtreg results). For now it
> just sits there looping through the repositories checking every 15
> minutes whether there have been updates (this should of course be
> triggered by a commit hook some day) and then does an autogen.sh &&
> configure && make && make check reporting any build failures or changes
> in test results it finds on the way (it reports them to everybody that
> made a change since it last checked, if that gets annoying please yell
> and we change it to only report to the mailinglist). Then it dumps the
> build, sources and test results (including all .jtr files so you can
> easily compare) at:
>
> http://icedtea.classpath.org/builds/
>
> Hope that is useful and can be extended to other repositories.
>
> It currently only has space for one build per repository. And sadly has
> to dump the documentation and debuginfo for now to preserve space. The
> build is done in a Debian Lenny i686 chroot environment. Which should
> produce binaries that run on most x86 GNU/Linux systems (Debian Lenny
> was chosen since it has both a pretty old glibc, but also a new enough
> gcj to bootstrap everything out of the box - well ok, and because the
> host was already running a x86_64 Debian etch variant, so setting up a
> lenny i686 chroot was pretty easy.).

Seems I forgot to actually attach the script or something stripped it
away. Lets try that again. Attached the quick-and-dirty build script
being used for now.

Cheers,

Mark

#!/bin/bash

# Copyright (C) 2009, Mark J. Wielaard <mark@...>
# This IcedTea build script is free software: you can redistribute it
# and/or modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation, either version 3 of the
# License, or (at your option) any later version.
# http://www.gnu.org/copyleft/gpl.html

# Where to send error reports, add committers later.
EMAIL=testresults@...

# Can we check somehow whether there is a build busy?
# http://www.davidpashley.com/articles/writing-robust-shell-scripts.html

if [ $# -ne 1 ]; then
 echo "build.sh takes one argument 6 or 7"
 exit -1;
elif [ "$1" != "6" -a "$1" != "7" ]; then
 echo "build.sh argument must be 6 or 7"
 exit -1;
fi

ICEDTEA_DIR=$HOME/icedtea$1
ICEDTEA_BUILD_DIR=$HOME/icedtea$1-build

# Build artifacts, sources and test results will be stored here.
RESULTS_DIR=/var/www/builds/icedtea$1

echo "Building $ICEDTEA_DIR"
echo " in $ICEDTEA_BUILD_DIR"
echo " results into $RESULTS_DIR"

cd $ICEDTEA_DIR
HG_LAST_ID=$(hg id -i -r tip)
echo "Last hg id: $HG_LAST_ID"

hg pull && hg update
HG_CURRENT_ID=$(hg id -i -r tip)

if [ "$HG_LAST_ID" == "$HG_CURRENT_ID" ]; then
  echo "Nothing to do last id: $HG_LAST_ID, equals current id: $HG_CURRENT_ID"
  exit 1
fi

echo "Rebuilding: last id: $HG_LAST_ID, current id: $HG_CURRENT_ID"

# HG Template for failure emails
TMPL='rev:  {node|short}\nuser: {author}\ndate: {date|date}\n\n{desc|strip}\n\n'

# Which people made changes between then and now?
USERS=$(hg log -r$HG_LAST_ID:$HG_CURRENT_ID --template '{author|email}\n' \
        | sort -u)

CHANGES=$(hg log -r$HG_LAST_ID:$HG_CURRENT_ID --template \
  'rev:  {node|short}\nuser: {author}\ndate: {date|date}\n\n{desc|strip}\n\n')

# echo "Changes made by: $USERS"
# echo "Changes: $CHANGES"

# Warn everybody that made changes in case something went wrong.
EMAIL="$EMAIL $USERS"

# Announce the test build coming up.
#(echo -n "Doing a test build for IcedTea$1"; echo; echo "$CHANGES") \
# | mail -s "IcedTea$1 build testing for $HG_CURRENT_ID" $EMAIL

# Remove both 6 and 7, there is only disk space for one build
echo "Removing old builds  ~/icedtea6-build ~/icedtea7-build..."
rm -rf ~/icedtea6-build ~/icedtea7-build

mkdir $ICEDTEA_BUILD_DIR

# Might contain old tar.gz/bz2 sources so we don't need to redownload.
# Don't worry if cp fails, we will download fresh ones.
SOURCES_DIR=$RESULTS_DIR/src
cp $SOURCES_DIR/*.tar.* $ICEDTEA_BUILD_DIR/

BUILD_LOG_FILE=$HOME/build-icedtea$1.log
echo "Putting build log in $BUILD_LOG_FILE"

# Make sure a failure in any command in a pipe, fails the whole pipe command.
set -o pipefail

# Build in separate dir.
# Figure out a way to use local openjdk tar.gz files
# maybe just copy to to an archive dir before cleanup and then copy back.
# Keep logs of build, and check if it was successfull
(cd $ICEDTEA_DIR && ./autogen.sh \
        && cd $ICEDTEA_BUILD_DIR \
        && $ICEDTEA_DIR/configure --disable-docs \
        && make) | tee $BUILD_LOG_FILE
BUILD_RESULT=$?

echo "Build result: $BUILD_RESULT"

if [ $BUILD_RESULT -ne 0 ]; then
  (echo "The current IcedTea$i build fails."; \
   echo "Possibly, but not necessarily, because of one of these changes:"; \
   echo; \
   echo "$CHANGES"; \
   echo; echo; \
   echo "Last part of build log: "; echo; \
   tail $BUILD_LOG_FILE) \
        | mail -s "IcedTea$1 build failed for $HG_CURRENT_ID" $EMAIL
  exit -1
fi

# Run tests under fake x-server so gui tests work "normally"
cd $ICEDTEA_BUILD_DIR && xvfb-run -e xvfb-errors -a -s -ac make check -k

# Old results are here, new results will be stored there.
TESTS_DIR=$RESULTS_DIR/test

cmp $ICEDTEA_BUILD_DIR/test/jtreg-summary.log $TESTS_DIR/jtreg-summary.log
TEST_RESULT=$?

echo "Test results compare: $TEST_RESULT"

if [ $TEST_RESULT -ne 0 ]; then
  (echo "The current IcedTea$i build test results changed."; \
   echo; \
   echo "Changed test results: "; echo; \
   diff -u $ICEDTEA_BUILD_DIR/test/jtreg-summary.log \
           $TESTS_DIR/jtreg-summary.log; \
   echo; \
   echo "More info at http://icedtea.classpath.org/builds/icedtea$1/"; \
   echo; \
   echo "Possibly, but not necessarily, because of one of these changes:"; \
   echo; \
   echo "$CHANGES") \
        | mail -s "IcedTea$1 test results changed for $HG_CURRENT_ID" $EMAIL
fi

# Need to fixup jtreg report html files.
# Escape paths for sed.
# From path is absolute build path on (chrooted) file system.
# To path is absolute (prefix) path on webserver.
FROM_PATH="\/home\/cpdev\/icedtea$1-build\/test\/"
TO_PATH="\/builds\/icedtea$1\/test\/"
for i in `find $ICEDTEA_BUILD_DIR/test/*/JTreport -name \*.html`; do \
         sed -i "s/$FROM_PATH/$TO_PATH/" $i; \
done

rm -rf TESTS_DIR
mkdir TESTS_DIR
cd $ICEDTEA_BUILD_DIR
mv test/*log test/jdk test/hotspot test/langtools $TESTS_DIR/

# Not enough room to keep the debuginfo, remove it for now.
find $ICEDTEA_BUILD_DIR/openjdk/build/linux-i586/j2sdk-image/jre/lib \
        -name \*.so \
        | xargs strip --strip-debug --preserve-dates

# Package up the resulting j2sdk-image dir.
cd $ICEDTEA_BUILD_DIR/openjdk/build/linux-i586
tar zcf j2sdk-image.tar.gz j2sdk-image

mv j2sdk-image.tar.gz $RESULTS_DIR/

# Store old tar.gz/bz2 source bundles, might be useful next time.
rm -rf $SOURCES_DIR
mkdir $SOURCES_DIR
mv $ICEDTEA_BUILD_DIR/*.tar.* $SOURCES_DIR/

# And the actual icedtea sources used.
rm -f $SOURCES_DIR/icedtea$1.tar.gz
cd $ICEDTEA_DIR && hg archive --type tgz $SOURCES_DIR/icedtea$1.tar.gz

[Mark Wielaard]

On Wed, 2009-06-10 at 09:52 +0200, Mark Wielaard wrote:

> On Mon, 2009-06-01 at 05:55 +0200, Mark Wielaard wrote:
> > On Sun, 2009-05-31 at 14:20 -0700, Kelly O'Hair wrote:
> > > Effectively what I'm thinking is a kind of cleanroom build of an openjdk
> > > forest, using Fedora 9 X86 32bit, and OpenSolaris X86 32bit to start.
> > > I'll create a simple self-extracting tarball installer (no rpm/deb/ips packages),
> > > and publish them in a public openjdk area.
> > > No testing to start, but adding testing with published results could
> > > be done by just about anyone.
> > > If I do this right, we can in theory point at any openjdk project forest
> > > and provide the same build service for any project.
> >
> > That sounds like a wonderful start!
>
> So I hacked together a quick script this weekend to do this for the
> IcedTea repos (attached below). It has been running for a couple of days
> now. It isn't the most shiny solution. But I wanted something that just
> worked for now. In the future we can think about extending it with fancy
> frontends (maybe hudson integration to show jtreg results). For now it
> just sits there looping through the repositories checking every 15
> minutes whether there have been updates (this should of course be
> triggered by a commit hook some day) and then does an autogen.sh &&
> configure && make && make check reporting any build failures or changes
> in test results it finds on the way (it reports them to everybody that
> made a change since it last checked, if that gets annoying please yell
> and we change it to only report to the mailinglist). Then it dumps the
> build, sources and test results (including all .jtr files so you can
> easily compare) at:
>
> http://icedtea.classpath.org/builds/
>
> Hope that is useful and can be extended to other repositories.
>
> It currently only has space for one build per repository. And sadly has
> to dump the documentation and debuginfo for now to preserve space. The
> build is done in a Debian Lenny i686 chroot environment. Which should
> produce binaries that run on most x86 GNU/Linux systems (Debian Lenny
> was chosen since it has both a pretty old glibc, but also a new enough
> gcj to bootstrap everything out of the box - well ok, and because the
> host was already running a x86_64 Debian etch variant, so setting up a
> lenny i686 chroot was pretty easy.).

This has been running for a week now and seems pretty nice as a start.
The builds seem usable as early access builds on a couple of systems I
tried them on (Debian and Fedora). And although it doesn't test each
commit individually (just because there are too many commits a day to
the 6 and 7 repos to do that) it does seem like a good way to catch any
issues early. The results are posted to the testresults mailinglist and
to each committer since the last run individually:
http://icedtea.classpath.org/mailman/listinfo/testresults

A couple of bugs have been fixed in the script:
- There was a typo in the TESTS_DIR moving, which prevented old results
  from being cleaned up.
- There was an off-by-one error in the changeset selection. Mercurial
  revision ranges are fully open and so contain both the start and end
  rev given. The script now bumps the (local) revision number by one.
- It now also sends email also when the build succeeded and the test
  results didn't change to signal the new changes were fine.
Diff attached.

There are a couple of improvements to make.
- It would be nice to combine this with the results reported by Omair,
  since his web reporting interface is so much nicer:
  http://icedtea.classpath.org/~omajid/testing.html
- The test results aren't fully stable, if you look at the changes you
  see that there are a couple of tests that sometimes succeed and
  sometimes fail. This causes too many "test results changed" emails.
  John VanAlten started a page to collect all failures on the wiki:
  http://icedtea.classpath.org/wiki/IcedTea_jtreg_bugs
  Hopefully we can even get to zero fail for normal runs.
- We could add some extra configure options, in particular to test the
  cacao and zero builds. Any others?
- It would be nice to make this more distributed and combine the test
  results from multiple machines running this build script in different
  setups somehow. I don't really have a plan for doing that yet though.

If this is helpful, if you used the early access builds, or couldn't use
them, if you know of other improvements needing to be made, or if the
build/result emails annoy you as committer to no end, please discuss.

Cheers,

Mark

[Jonathan Gibbons]

On Jun 14, 2009, at 8:13 AM, Mark Wielaard wrote:
>
> - It would be nice to make this more distributed and combine the test
>  results from multiple machines running this build script in different
>  setups somehow. I don't really have a plan for doing that yet though.

Note that jtdiff (distributed with jtreg) is designed to be able to  
compare
test results from test runs on different machines, or on different days,
or both together, in a 2D matrix of test results.

-- Jon