As I see it, a "build and test system" has 3 significant components.
1. "build" -- thanks to the build-infra team, we've made great progress
in this area to modernize and streamline the build process.(OK, there
are still some warts that need to be addressed, like closed configure
files.)
2. "test" -- the main problem here is having a robust and reliable set
of tests that can be run after each build. As you can see here[1], we
are not there yet. A number of people in the core-libs team and more
have been working on this issue, but there's still more work to do.
3. "system" -- the good news here is that there are better options for
an off-the-shelf starting point that there were when systems like "otto"
and JPRT were designed.
-- Jon
[1] http://download.java.net/jdk8/testresults/archive-index.html
On 03/06/2013 01:11 AM, Martijn Verburg wrote:
Hey All,
As an aside to this - we're looking to build a distributed build farm that
will enable folks to test changes on at least the common platforms. If you
want to help out (especially if you have Build/Jenkins/CI/Git/Mercurial
expertise) then please drop me a note off-list.
Cheers,
Martijn
On 6 March 2013 01:00, David Holmes <david.hol...@oracle.com> wrote:
On 6/03/2013 10:52 AM, Martin Buchholz wrote:
On Tue, Mar 5, 2013 at 4:36 PM, David Holmes <david.hol...@oracle.com
<mailto:david.holmes@oracle.**com <david.hol...@oracle.com>>> wrote:
I disagree. The submitter should be responsible for the "right"
amount of
upfront testing.
Now you are confusing me :) You disagree but say the responsibility
is on the submitter. Well I certainly agree with that! Our
difference is the notion of "right". I maintain that for a change to
the build instructions of a given platform, then a test build on
that platform is the absolute minimum upfront testing that must be
done.
The responsibility is on the submitter to be "responsible". But there's
a limit to the certainty of correctness you can expect from the
submitter. The integration process (including gatekeepers) needs to
help out as well.
If:
- erroneous commits only cause lost work for the submitter and the
gatekeeper
- erroneous commits can be trivially rolled back
- testing is highly automated
then we can have a more productive and pleasant developer experience for
everyone.
None of these premises hold with the current system. You can lament or
debate that all you like but the facts remain. So in the current system it
is not acceptable, in my opinion, to push a change that includes build
instructions for platform X without a build of platform X having been
tested. So if a submitter can't do that test themselves then they need to
collaborate with someone who can.
David
