[Users] Meeting Minutes

[Roland Haas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Bruno, all,

Disclaimer: these are my personal opinions and do not necessarily
reflect the general ET maintainer's consensus.

> Is there a list for these thorns under heavy development? Could we
> say that GRHydro and Carpet are under heavy development? Even for a
> thorn in heavy development I assume there still is a maintainer of
> that thorn that should organize how the patches should be applied,
> no? It would be useful to make this policy clearer, but it is
> interesting this soften requirements.
Those are the natural candidates I think. This is part of the a larger
push to finally have trunk (or master) see development. They were
never intended to be "stable". If you pull trunk/master then your code
is expected to break (more or less often). Right now we have the
unfortunate situation that trunk is basically never used for anything
other than producing the release version.

> What about patches to thorns that nobody else seems to care besides
> the patch author? Was there any change of policy? It is common to
> see patches on Trac sometimes for weeks or months just waiting for
> being reviewed. People are just too busy or sometimes they just
> don't care for that particular patch. In those cases where a patch
> doesn't attract any discussion on Trac, shouldn't it just be
> applied after a week or so of silence?
That is basically what happens with GRHydro right now. I put the ones
that have been produced at Caltech (for example, very little
development on GRHydro anywhere else right now) up for review once a
week, with the admonishment that I will push after a week unless there
are objections. This is not what is currently in the book but the only
way to not have a hundred accumulated patches at one go.

> That forces everyone with a patch to offer to have an account on 
> bitbucket (or github), no? Besides how do you envision the support
> for forked repositories in GetComponents?
That should already work. GetComponent can pull from any URL. So if
you want to use your own forked repository (on bitbucket or on your
private server or on github) you have to change the URL. This is
identical to what you have to do right now for subversion (or if eg
you have your own copy of Carpet). As far as keeping your fork up to
date with changes upstream, that is something you have to take care of
yourself. If our changes are small, then periodically pulling and
merging might be sufficient but if your bitbucket-fork turns into an
actual fork (that is an independent code that started off as being a
copy of the original) then tracking changes in the original code can
become much more difficult.

You can always do (obviously) anything you want in your own private
copies of repositories. It does not really require you to get an
account on bitbucket. You can also make your own repository (with a
branch for_ET or so) available trough the web and request for changes
to be pulled from there. Not so nice to do for the person pulling in
the changes so you might have fewer patches pulled (or have them
reviewed positively) that way. There seems to be no way around this.
Gettign an account on bitbucket is still much easier than getting for
example a CCT account if we were to try and run our own repos (I think.

Yours,
Roland

- -- 
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://keys.gnupg.net.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlM5rHAACgkQTiFSTN7SboUrvgCfWKFVkqVIo2F22J+bXqA5EsFd
8PgAni1UFY4+y08VGbm1LQ2nJb1EGaLt
=kbj4
-----END PGP SIGNATURE-----