[Users] Meeting Notes Jun 1st

[Frank Loeffler]

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 at 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20100601/f02246d2/attachment.bin