[Users] Meeting Minutes

[Roland Haas]

Present: Frank, Roland, Peter, Erik, Matt, Ian, Josh, Maria, Yosef, Philipp

git to svn transition:

* Ian (and other contributors) created a wiki page outlying ideas for
how to organize repositories:
https://docs.einsteintoolkit.org/et-docs/Version_control

* majority of call participants prefer git over svn, points mentioned
are easier management of branches and patches and availability of
powerful GUIs
* suggest using GUIs even for "advanced" users. For git there is
SourceTree for OSX and SmartGit or GitEye (see
http://git-scm.com/downloads/guis)

Goals to achieve while moving the repositories, some of which might be
conflicting, in no particular ordering:
* simplify exchanging patches, in particular patches for review where
right now we exchange patch files, instead we might want to point to a
revision in a branch or private repository
* consistency of thorns in toolkit is easier to achieve is strongly
dependent thorns are in a single repository
* simplify work-cycle for developers, read-only access for end-users is
already provided by GetComponents
* minimize amount of code downloaded
* keep modularity of framework, avoid monolithic repository

Opinions:
* consistency is given low priority, instead require framework to
enforce this (eg via interface.ccl etc).
* avoid overly large repository with many unrelated thorns
* using branches and cherry picking commits to choose a working set of
thorns that mixes cutting edge versions of some thorns and bugfix-only
versions of another is hard to do, takes lots of time.
* we lack the manpower to keep a always working mainline for all thorns,
GRHydro currently follows this paradigm and requires ~0.5 days a week to
choose and push patches. The advantage is that Zelmani can do whatever
it wants and does not have to worry about "external" users pulling code
that contains bugs. This is not in line with the ET philisophy of having
trunk branches under development then releases every 6 months.

Hosting:
* Frank (who will be admin) advertises to host the git repos at CCT, Ian
suggests using gitolite as the front-end which uses a plain git
repository for admin task (keeps record of admin actions)
* desire to be able to automate actions on multiple repositories
(assuming we will have multiple/many repositories)
* suggestion to consider bitbucket/github as external hoster for speed
and/or certificate issues, did not find much support
* want to make sure that certificates work and that speed is acceptable
* rather spend some money than spend time
* bitbucket might be a viable option when using teams and would simplify
infrequent tasks, major problem is scriptability
* github source code made be available to use even for locally hosted
repos if we want a web-based UI, Ian to test this

Proposed repository structure:
* structure not fully decided on, use wiki page (see above) as location
to hash out proper layout

Yours,
Roland

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20130812/4dc7d24e/attachment.bin