New build system problems

[Jonathan Gibbons]

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.holmes at 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.holmes at oracle.com
>>> <mailto:david.holmes at oracle.**com <david.holmes at 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
>>
>>
>>