Hi,
here are the notes of today's meeting:
The main topic was how the future development of the ET should happen.
First, Erik explained what the current (not yet that old) policy states:
1 There will be stable branches from time to time 2 There is one development branch for most of the development 3 There might be extra branches if wished for. Commits to 1 and 2 have to have a review, unless they are trivial, development in 3 is up to the maintainer of that branch.
Christian and Roland (?) said they thought the reviews only apply to 1, not also 2.
Frank suggested to go with Christians email-suggestion, which would: - try to avoid branches, but might have - have stable branches - have (almost) free development in /trunk Frank noted that in order to achieve stable branches, a more or less regular freeze of /trunk would be necessary: no further development, only bug fixes.
One of Christian's arguments against a lot of branches was that keeping them in sync with the main development branch takes a lot of time which could be better spent. This often leads to diverging branches which are never really merged.
Ian Hinder generally does not mind to handle multiple branches.
Roland Haas suggested to maybe add one more level: in addition to stable and development there could be an experimental branch which would be free for any type of development while the development branch is only updated from the experimental branch from time to time, as the stable branch is from the development branch. This didn't find another supporter.
Erik noted that with free development inside /trunk (the development branch) it would not be stable enough to be used for production - anything might break after an update. This means there have to be regular updates of the stable versions from the development version to be able to take advantage of new features. Erik asked what a good time for such a cycle would be and suggested 3-6 months. Nobody objected.
Everyone was requested to voice her/his opinion about this topic, and everyone on the call (except Pablo, who had dropped off) agreed on Christian's suggestion (with a few additions from todays meeting):
1 There will be stable branches from time to time, targeting at about every 3-6 months. Commits to these branches needs a code review unless trivial. 2 Most of the development will happen in the development branch, which is /trunk. No special policy for commit is in place there, common sense rules. 3 There will be a freeze from time to time to move changes in the development branch to a new stable branch. When and how long such a freeze happens will be discussed. 4 There might be extra branches with their maintainers being responsible to enforce any policy they like.
Erik suggested to start with a freeze to get a first stable release before starting to implement MHD into GRHydro. He estimated the time to 1-2 weeks. Christian agreed that this delay wouldn't be a problem for the MHD development.
Christian asked if there is a tutorial of how to create a good testsuite, but nobody could name something like that apart from a small part of the Cactus documentation. Everybody agreed that this should be improved, but nobody volunteered to be responsible for this. So: everyone is invited to see if she/he could add tips to the Cactus documentation.
It was also noted that most discussions should happen on the users@einsteintoolkit mailing list and only the "boring administrative stuff" should be sent to the maintainers list.
Last but not least, the main topic for next week's meeting will be how MHD will be implemented in GRHydro: figuring out who does what and probably also how and when.
Next week's meeting will take place at it's usual time: Mon, Jun 7th at 10am CDT, with the usual phone information:
Each participant of the teleconference will call 578-4942 (225-578-4942 from off-campus or 866-573-0359 toll free).
Participants will press 118682# for Conference Line one.
Frank