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

[Andrew Hughes]

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

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07