<p dir="ltr">Hi,</p>
<p dir="ltr">It's submitted to master already, so just rebase to HEAD as/when you want.</p>
<p dir="ltr">Mark</p>
<br><div class="gmail_quote"><div dir="ltr">On Sun, 6 Sep 2015 15:25 David van der Spoel <<a href="mailto:spoel@xray.bmc.uu.se">spoel@xray.bmc.uu.se</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 02/09/15 23:12, Mark Abraham wrote:<br>
> Hi devs,<br>
><br>
> With 5.1 off the table, we're implementing some much-needed updates to<br>
> the way we handle Jenkins verification of GROMACS.<br>
><br>
> Teemu's rewritten the scripts we use to implement the various kinds of<br>
> verification jobs, which will let us maintain and extend in much less<br>
> ad-hoc fashion. Some parts of those scripts will now live in the GROMACS<br>
> source repository, so that they can change in step with code changes.<br>
> We've already submitted that script to master, so when you rebase<br>
> patches over 0ce920a017, Jenkins will be able to use its new toys.<br>
<br>
So is this the reason that most patches fail right now?<br>
Where is this patch in gerrit? I can not seem to find it...<br>
<br>
><br>
> We'll probably submit the half of the scripts that live in the releng<br>
> repo shortly, and when we do, we'll make a new set of voting<br>
> verification jobs named like the old ones, but with "-new-releng"<br>
> suffix. These will all fail, unless a patch under review has been<br>
> rebased to pick up the above commit. We plan to rebase a few commits to<br>
> check the new gear is stable. Please feel free to rebase your commits<br>
> and upload to Jenkins, but please check that Jenkins already doesn't<br>
> have a hundred tasks in its queue, and don't rebase all your commits at<br>
> once. Hopefully after a few days, we'll feel things are working well,<br>
> and we will de-activate the old verification jobs and rely on the new ones.<br>
><br>
> We then plan to rework the matrix of things that we get Jenkins to test<br>
> every time code is uploaded to gerrit (ie. pre-submit), and use other<br>
> matrices of build configurations and test types that run only after we<br>
> submit code, or weekly, etc. This will cover a bunch of known test<br>
> coverage gaps, and hopefully not too many unknown bugs will be found :-)<br>
><br>
> At some point soon, we will probably move the matrix descriptions into<br>
> the source repository, so we have a record of what build configurations<br>
> and tests were supposed to pass on that code version. That might require<br>
> another round of rebasing - you'll hear if that's the case.<br>
><br>
> At some point soon, we plan to re-implement the build slaves that<br>
> Jenkins uses, probably based on Docker containers running in a<br>
> dynamically provisioned way on a bunch of old hardware we salvaged. This<br>
> should give us reproducible testing behaviour. We should be able to<br>
> spend less time on ongoing Jenkins maintenance. It should be easier for<br>
> us to add a bunch of hardware during release periods for more rigorous<br>
> testing. We can probably separate the compilation phase from the test<br>
> phase (lowering the pressure on our machines with real target hardware<br>
> in them). Debugging a problem reported in Jenkins will be easier if<br>
> developers can get the Docker image that failed, and perhaps then run it<br>
> on their desktop. Otherwise, hopefully we can extract the build and test<br>
> artefacts from the Docker images, and publish them on Jenkins in the<br>
> usual way.<br>
><br>
> Any bright ideas, or other feedback is welcome. We'll keep you posted of<br>
> developments :-)<br>
><br>
> Mark<br>
><br>
><br>
<br>
<br>
--<br>
David van der Spoel, Ph.D., Professor of Biology<br>
Dept. of Cell & Molec. Biol., Uppsala University.<br>
Box 596, 75124 Uppsala, Sweden. Phone: +46184714205.<br>
<a href="mailto:spoel@xray.bmc.uu.se" target="_blank">spoel@xray.bmc.uu.se</a> <a href="http://folding.bmc.uu.se" rel="noreferrer" target="_blank">http://folding.bmc.uu.se</a><br>
--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
</blockquote></div>