PING: [PATCH] Enable debug info on all libraries for OpenJDK builds

[David Holmes]

Andrew,

My sincerest apologies. As long as pushes are to jdk8/build then there 
is indeed scope for deferring broad testing until after the push - any 
failures will only affect users of the jdk8/build and a fix will likely 
swiftly occur. In any case that is for the build folk to concern 
themselves with.

Having been burnt by some recent build issues in other repos I 
overlooked the key factor as to which repo is involved.

Again my apologies.

David

On 11/04/2013 12:30 PM, David Holmes wrote:
> Hi Andrew,
>
> We live/work in an imperfect world. The shortcomings you outline below
> are well known and steps are being taken to address at least some of
> them. That has taken time and will continue to take time - there is
> nothing I can do about that - sorry. I too would love to see an
> automatic submission system (like JPRT) that is accessible to all so
> that I don't have to ever worry about build failures getting through.
>
> In the meantime I don't think my request to work with others to ensure
> broader test coverage of build changes is unreasonable.
>
> I can't force anyone's cooperation I can only request it.
>
> Thanks,
> David
>
> On 10/04/2013 11:35 PM, Andrew Hughes wrote:
>> ----- Original Message -----
>>> On 9/04/2013 11:06 AM, Martin Buchholz wrote:
>>>> On Mon, Apr 8, 2013 at 5:51 PM, David Holmes <david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>>
>>>>      On 9/04/2013 2:59 AM, Andrew Hughes wrote:
>>>>
>>>>          Well, if I push it, it will be, no?
>>>>
>>>>      Testing comes before pushing - thank you.
>>
>> And I have built and tested it.  You are trying to impose additional
>> requirements
>> for building on platforms we don't use.  This simply does not scale.
>> You can't
>> expect every OpenJDK committer to build on four operating systems and
>> however
>> many architectures (potentially any in existence, given the presence
>> of Zero).
>>
>> If I'm a little unforgiving here, it's because I don't see the same
>> thought being
>> applied in the other direction.  This is not a patch to add a new
>> feature, but
>> to fix a build regression introduced by Oracle engineers (and one of
>> many we've
>> found).  I wouldn't even have to submit this if debugging had not been
>> completely
>> broken in our builds with little clear explanation as to why.
>>
>>>>
>>>>
>>>> This issue keeps coming up.
>>>>
>>>> Non-Oracle committers have no access to the Oracle automated testing
>>>> submission system, so I suggest giving developers some slack when
>>>> submitting (as I did when I was TL integrator). Or provide some other
>>>> simple mechanism for handing off risky patches to the integration
>>>> pipeline.  Or provide some easy way to roll back breaking changes.
>>
>> +1.
>>
>>>
>>> If you are submitting a build patch that affects multiple platforms and
>>> you can not test on all the platforms yourself then you should work with
>>> someone who can assist in ensuring sufficient testing is carried out. I
>>> don't think that is at all unreasonable.
>>
>> The problem here is not the concept in general, but that both "someone"
>> and "sufficient testing" are defined relative to Oracle.  Could I work
>> with someone at Red Hat, Google or IBM to carry out "sufficient testing"?
>> It seems doubtful to me, and that's without even considering
>> contributions
>> from those not working for a company.
>>
>> As far as I can see, "sufficient testing", from an Oracle perspective,
>> would include
>> testing on e.g. Solaris/SPARC, which is mainly of relevance to them, but
>> not testing on Linux/SPARC (which Debian & Fedora build) or AIX/PPC
>> (which
>> IBM are working on).
>>
>> I agree build testing is important, and no-one wants to find the build
>> broken
>> (I've hit it enough times as the result of work from Oracle
>> engineers), but such
>> a restriction can't be imposed unless resources are available to
>> support it.
>> Pushing a patch and having automated build systems test it on all the
>> various
>> setups is a lot more scalable than waiting for someone else to apply
>> and build it
>> locally.  It's not like anyone's going to release binaries if OpenJDK
>> is not buildable,
>> is it?
>>
>> This issue is important not for people like me who have to work on
>> OpenJDK anyway, no
>> matter how much pain and aggravation it is, but in terms of the
>> "onboarding" of new
>> developers.  These sort of issues are acceptable in a new project.
>> OpenJDK is now six
>> years old, but non-Oracle users can't even create bugs or commit to
>> HotSpot.  I'm not
>> even talking about new committers but people like me who have been
>> working on OpenJDK
>> for all of those six years and have reviewer status.  I can review a
>> patch for OpenJDK
>> but the person I reviewed it for can't then commit it until an Oracle
>> employee gives
>> them a bug ID for it.
>>
>> If OpenJDK is going to grow and attract new developers, these issues
>> need to be sorted.
>>
>>>
>>> We have had a number of build related changesets recently (Oracle
>>> generated!) that have caused significant build failures on some
>>> platforms, which in turn causes significant disruption to a number of
>>> teams. So I don't think the importance of testing before pushing can be
>>> overstated here.
>>
>> But if they were Oracle generated, surely they went through your tests
>> and
>> they didn't catch it?  Or are you referring to testing prior to commit?
>>
>>>
>>>> There's a far greater risk from changes that pass all the tests today,
>>>> but have a fatal flaw that won't be discovered till after release, IMO.
>>>
>>> Totally different problem.
>>
>> Not really, because this includes build issues that occur from paths
>> through
>> the build that Oracle just don't test.  An example would be the recent
>> timezone
>> tool issue that we picked up because we do a build with the just-built
>> JDK but
>> slipped through Oracle's testing to the point of being in a promoted
>> build.
>>
>>
>>>
>>> David
>>>
>>