Hi all, We're looking to help alleviate these sorts of issues with the Betterrev project. Basically patches will get build against common platforms/forests and results sent back to the submitter and the appropriate OpenJDK mailing list.
We still have some way to go, but early work is looking promising. If anyone has spare cycles and a passion for build and CI, please drop me a note! Cheers, Martijn On 11 April 2013 03:59, David Holmes <david.hol...@oracle.com> wrote: > 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.holmes@oracle.**com <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 >>>> >>>> >>>
