Present: Frank, Roland, Erik, Peter, Matt, Steve
transition to git: * soften commit requirements, no longer require review for every change for thorns under heavy development * restrict commits just before release * when using git, no longer propose patches but instead use pull requests
Yours, Roland
Hi Roland,
just a few questions:
On 03/31/2014 06:45 PM, Roland Haas wrote:
Present: Frank, Roland, Erik, Peter, Matt, Steve
transition to git:
- soften commit requirements, no longer require review for every change
for thorns under heavy development
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.
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?
- restrict commits just before release
- when using git, no longer propose patches but instead use pull requests
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?
Cheers, Bruno.
Yours, Roland
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On Mon, Mar 31, 2014 at 07:35:59PM +0200, Bruno Coutinho Mundim wrote:
Is there a list for these thorns under heavy development?
I don't think there will be a list of "heavy development" thorns. The intention here was more on "because it benefits those most". It would apply to all thorns, assuming good judgement of the authors. A patch to the flesh that could disrupt everyone's work should probably still get a review for example.
It would be useful to make this policy clearer, but it is interesting this soften requirements.
Outside of a release-window I that everyone with write access has enough discipline and good judgement to make the best decision, at least most of the time - and for the "other times" we have svn/git.
The main problem I see (and not just me) is that the current strict policy is discouraging development.
What about patches to thorns that nobody else seems to care besides the patch author?
As long as this doesn't break anything for somebody else, or makes the code harder to read/maintain, I don't see a reason against this. In other cases it might make sense to discuss this.
Was there any change of policy? It is common to see patches on Trac sometimes for weeks or months just waiting for being reviewed.
Sadly - yes.
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?
I would think we are all mature enough to judge about that in each particular case. If you think that a particular patch should be tested before you commit it, then ping everyone again after a while - if necessary at the phone call, or (not preferred) by personal email.
- restrict commits just before release
- when using git, no longer propose patches but instead use pull requests
That forces everyone with a patch to offer to have an account on bitbucket (or github), no?
We would still accept patches via trac of course, we would just ask to provide patches via git if the author is able and willing to do that.
Besides how do you envision the support for forked repositories in GetComponents?
Forked repositories have a distinct URL, different from the origin. I don't think we need extra support for it - it should already work. As for testing pull requests: I don't think people would use GetComponents to switch between forks, but rather whatever tool the developer is comfortable with - quite likely a special git utility.
Frank
Hi Frank and Roland,
thanks for your replies! Regarding the patching system proposed via fork and pull requests it just seems to me more work than necessary, specially to someone who is new to git. You would need to fork the repository (and end up with a new URL as you pointed out), add this new repo as a remote to your local clone, do the work there, push it to the repo and request a pull to the official ET repo. On the other hand, the alternative of creating a local branch, do the work, diff between master and new branch and send it to Trac seems more attractive. Anyways since you don't plan on imposing either way or the other people at the end can choose what works better for them.
Cheers, Bruno.
On 03/31/2014 07:54 PM, Frank Loeffler wrote:
On Mon, Mar 31, 2014 at 07:35:59PM +0200, Bruno Coutinho Mundim wrote:
Is there a list for these thorns under heavy development?
I don't think there will be a list of "heavy development" thorns. The intention here was more on "because it benefits those most". It would apply to all thorns, assuming good judgement of the authors. A patch to the flesh that could disrupt everyone's work should probably still get a review for example.
It would be useful to make this policy clearer, but it is interesting this soften requirements.
Outside of a release-window I that everyone with write access has enough discipline and good judgement to make the best decision, at least most of the time - and for the "other times" we have svn/git.
The main problem I see (and not just me) is that the current strict policy is discouraging development.
What about patches to thorns that nobody else seems to care besides the patch author?
As long as this doesn't break anything for somebody else, or makes the code harder to read/maintain, I don't see a reason against this. In other cases it might make sense to discuss this.
Was there any change of policy? It is common to see patches on Trac sometimes for weeks or months just waiting for being reviewed.
Sadly - yes.
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?
I would think we are all mature enough to judge about that in each particular case. If you think that a particular patch should be tested before you commit it, then ping everyone again after a while - if necessary at the phone call, or (not preferred) by personal email.
- restrict commits just before release
- when using git, no longer propose patches but instead use pull requests
That forces everyone with a patch to offer to have an account on bitbucket (or github), no?
We would still accept patches via trac of course, we would just ask to provide patches via git if the author is able and willing to do that.
Besides how do you envision the support for forked repositories in GetComponents?
Forked repositories have a distinct URL, different from the origin. I don't think we need extra support for it - it should already work. As for testing pull requests: I don't think people would use GetComponents to switch between forks, but rather whatever tool the developer is comfortable with - quite likely a special git utility.
Frank
-----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.
users@lists.einsteintoolkit.org
-
Bruno Coutinho Mundim -
Frank Loeffler -
Roland Haas