Hi,
In addition to a discussion and decision on language standard and old
compiler support (for Amber 17) at the Amber developers meeting,
I suggest a discussion about release schedules.
I recommend a stricter schedule and with a more whole community
focus on quality assurance - to wit a halloween code freeze for a tax
day release, a separate release candidate branch, a mandate that developers
use the release candidate branch to reproduce production work, etc.
Grabbing from the [AMBER-Developers] pmemd.MPI build broken thread:
On Sat, Mar 05, 2016 at 07:50:04AM +0000, Charles Lin wrote:
> ... Its been thoroughly tested with intel, gnu, and mpich though.
> >> > On Sat, Mar 05, 2016, Jason Swails wrote:
> > 2) Wait to release it until a wider audience of developers have actually
> > gotten a chance to use it.
> > This is a large part of why we institute a code freeze well before release.
Thoroughly tested is a high standard. It requires evidence. For a release
candidate, in the absence of counterevidence, i would find this persuasive:
source, tests, and docs in the release candidate branch for 1/2 year so that
the whole community has had access and it's been routinely built and tested.
Reproduction of published work by and vetting of new features in several
research groups.
> >> > On Sat, Mar 05, 2016, Jason Swails wrote:
> > Mixed OpenMP-MPI has its place for sure -- MICs and dedicated
> > supercomputers with many cores per node. But for commodity clusters and
> > single workstations, I see this as more of an obstacle than a benefit.
There will be different perspectives. Rushing the schedule tends to
crank up the issues. Let's go slower, give more people a chance to
comment, and give ourselves a better chance to meet our high standards.
scott
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Mar 10 2016 - 11:00:03 PST
