Re: 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.hol...@oracle.com
<mailto:david.hol...@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