Post by Roland SchulzHi,
I think we also need to do something about the "Not enough memory."
errors with which the MdrunTests sometimes fails. It is currently probably
one of the leading causes of false positives. Example:
http://jenkins.gromacs.org/job/Gromacs_Gerrit_5_0/958/. Not sure if it is
enough to increase the memory or decrease the number of jobs executed in
parallel.
I only ever see that one when building on a VM, but never via Jenkins! I
suspect it is some data structure in grompp having state and/or not being
initialized properly, but having virtual memory on a real machine makes it
go unnoticed. The problem could probably be found by noting whenever snew
tries to allocate more than (say) 1MB, but I haven't prioritized doing it.
Mark
Post by Roland SchulzRoland
Post by Mark AbrahamPost by Roland SchulzHi,
I suggest we change the gerrit setting change.largeChange from 500 to
1000 (at what point the size bar is red).
Post by Roland SchulzPost by Mark AbrahamSounds good for the forseeable future. Not sure where it is - if you
know, please do it.
Post by Roland SchulzPost by Mark AbrahamPost by Roland SchulzAlso I think we should try harder to break changes into small easy
reviewable patches. Changes such as: https://gerrit.gromacs.org/#/c/3471
are too big to be reviewed efficiencly.
Post by Roland SchulzPost by Mark AbrahamTrue, but it'd be nice also if we were all a little more cooperative
with reviewing low-impact patches (e.g. clean up or file renaming that
doesn't change functionality) so that people aren't tempted to write
monolithic patches (where, when their ship comes in, they all come in at
once...). For example, having gone a fair way into development of 3471,
David might recognize that he could split that patch into
Post by Roland SchulzPost by Mark Abraham1. move the existing functionality into the newly named files, get most
of the tools to call it from the new place in the old way
Post by Roland SchulzPost by Mark Abraham2. import lmfit, change existing functionality to use it, add tests
3. any genuinely new stuff (if any; not apparent to me right now)
Patch 1 ought to be easy and fast to review (no functional changes), and
patch 2 should be faster to review than 1+2 altogether. Today, I did some
review on "new-seeming" code in 3471 that upon closer inspection was just
old code moved to a new file - had I submitted that part of my review,
David would likely have had to say "well, sure, but that's not code I
wrote, or that I'm working on here." The split of 1 & 2 would make that
clear to reviewers up front.
Post by Roland SchulzPost by Mark AbrahamThat said, I've had poor experiences with (say)
https://gerrit.gromacs.org/#/q/topic:g-tune-pme-reform, where people have
reviewed some changes and not enough people have reviewed their pre-reqs,
etc. I have a bunch more (IMO) decently atomic commits for fixing tune-pme
sitting in a long-forgotten repo on a drive... I can't say
https://gerrit.gromacs.org/#/q/topic:bondeds has been a compelling
experience, either. I don't mean this as criticism of any one or any group
- but I do think that with more than 100 outstanding patches in Gerrit and
a long-time-average merge rate of about 2 per day (
https://gerrit.gromacs.org/#/q/project:gromacs+status:merged), we all need
to pitch in harder with review and review-response, and less on doing our
own cool new things.
and XCode 5.1. Everything should be usable, do yell if not! If bs_mac + icc
still misbehaves then we'll bump icc version or something.
the issue that the matrix job isn't canceled when a newer change is
uploaded: https://issues.jenkins-ci.org/browse/JENKINS-24295
include the patch isn't out yet. Let me know - it should be easy for me to
build it.
then we can deploy it without taking gerrit down.
Post by Roland SchulzPost by Mark AbrahamPost by Roland SchulzPost by Mark AbrahamMark
Post by Roland SchulzRoland
On Sat, Sep 13, 2014 at 7:28 AM, Mark Abraham <
Post by Mark AbrahamHi,
The Jenkins Mac build slave needs an OS upgrade to keep up with
Xcode versions, which we hope will fix the way the mac+icc CI build
segfaults occasionally. Rossen's going to do that on Monday. There's a
newer Gerrit version out that has a bug fix that I'm keen to use, so I'll
also upgrade Gerrit on Monday so we have less overall downtime. Jenkins and
Redmine are probably OK for now. We should bump our icc versions, but we
don't need a downtime for that. Anything else people can think of we should
fix?
Post by Roland SchulzPost by Mark AbrahamPost by Roland SchulzPost by Mark AbrahamPost by Roland Schulz--
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
--
Gromacs Developers mailing list
* Please search the archive at
http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
posting!
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or
Post by Roland SchulzPost by Mark AbrahamPost by Roland Schulz--
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
--
Gromacs Developers mailing list
* Please search the archive at
http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
posting!
Post by Roland SchulzPost by Mark AbrahamPost by Roland Schulz* Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
--
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
--
Gromacs Developers mailing list
* Please search the archive at
http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
posting!
Post by Roland Schulz* Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
or send a mail to gmx-developers-***@gromacs.org.