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
