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

[David Holmes]

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