On 23 Nov 2015, at 18:02, Roland Haas <[email protected]> wrote:
> Present: Frank, Roland, Yosef, Eloisa, Erik > > HDF5 auto-detection: > * Yosef reports that some installations use a file H5pub.h H5pub_x86.h > (or similar) > * Yosef will create a ticket > > Tracers in GRHydro: > * implement Ian Hawke's proposed solution > > LORENE: > * provide LORENE thorn LORENE format introduced > * poll users and once majority uses the newer version, then switch over > > Release process: > * Roland asks for opinions on the release process > ** timeliness > ** care taken releasing it > ** participation of maintainers > * Erik mentions that if there are no large changes and the community > does not request them this frequent, then it may not be required to have > a release every 6 months > * Frank uses regular 6 monthly releases so that there is a fairly modern > released and tested version to base new projects off > * Roland suggests that a release should have a clear "extra value" > compared to trunk from two weeks ago. Suggest to have a major new > feature (like IllinoisGRMHD, or MHD) or at least if we claim it to be > stable code we should be able to show proof of this by having some > largish science simulations that are doable > * Eloisa suggests to not insist on this to stringently on always having > a major new feature and set a goal that is so ambitious that we let the > releases slip. Having fewer releases may not actually mean less work > overall since larger intervals accumulate more changes that are then > harder to track. > * suggestions for groups: > ** showcase about DG methods from Erik > ** BNS with Llama from Roland > ** Yosef help for BBH > > There will be a ET meeting next week Monday again (after US Thanksgiving). Hi, Apologies for missing the call; I have a conflicting telecon. One thing which is not mentioned above is the value of having the release for making sure that it still runs and the tests pass on most machines. I think that this is a sufficient justification for making a release every 6 months, even if there are no new features. Both the code and the machines change with time, and there is no guarantee that the last release still works on updated clusters, and no guarantee that the tests will still pass on all machines after the code changes that were in trunk. I think the thing that concerned me slightly about this release was the number of failing tests across the machines which were tested. https://build.barrywardell.net/view/EinsteinToolkitMulti/job/EinsteinToolkitReport-sandbox/ We only had 4 machines which passed all the tests. For me, the greatest value in a release is the "quality assurance" that comes with it. This was one of the aims of the ET in the first place. I think I was not paying enough attention at the time of the release, but was it discussed on a telecon that we were "ready to release", and this decision signed off on by some of the maintainers? I wasn't actually aware that it was final before receiving the email from Frank to the list. -- Ian Hinder http://members.aei.mpg.de/ianhin
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
