commit rights for Nathaniel
Hi All, Numpy is approaching a time of transition. Ralf will be concentrating his efforts on Scipy and I will be cutting back on my work on Numpy. The 1.7 release looks to be delayed and I suspect that the Continuum Analytics folks will become increasingly dedicated to the big data push. We need new people to carry things forward and I think Nathaniel can pick up part of the load. Chuck
On Sun, Jun 3, 2012 at 6:43 PM, Charles R Harris <charlesr.harris@gmail.com>wrote:
Hi All,
Numpy is approaching a time of transition. Ralf will be concentrating his efforts on Scipy
I'll write a separate post on that asap.
and I will be cutting back on my work on Numpy.
I sincerely hope you don't cut back on your work too much Charles. You have done an excellent job as "chief maintainer" over the last years. The 1.7 release looks to be delayed and I suspect that the Continuum
Analytics folks will become increasingly dedicated to the big data push. We need new people to carry things forward and I think Nathaniel can pick up part of the load.
Assuming he wants them, I am definitely +1 on giving Nathaniel commit rights. His recent patches and debugging of issues were of high quality and very helpful. Ralf
On Sun, Jun 3, 2012 at 12:04 PM, Ralf Gommers <ralf.gommers@googlemail.com>wrote:
On Sun, Jun 3, 2012 at 6:43 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
Hi All,
Numpy is approaching a time of transition. Ralf will be concentrating his efforts on Scipy
I'll write a separate post on that asap.
and I will be cutting back on my work on Numpy.
I sincerely hope you don't cut back on your work too much Charles. You have done an excellent job as "chief maintainer" over the last years.
The 1.7 release looks to be delayed and I suspect that the Continuum
Analytics folks will become increasingly dedicated to the big data push. We need new people to carry things forward and I think Nathaniel can pick up part of the load.
Assuming he wants them, I am definitely +1 on giving Nathaniel commit rights. His recent patches and debugging of issues were of high quality and very helpful.
OK, I went ahead and added him whether he wants it or not ;) Chuck
On Tue, Jun 5, 2012 at 4:19 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Jun 3, 2012 at 12:04 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Sun, Jun 3, 2012 at 6:43 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
Numpy is approaching a time of transition. Ralf will be concentrating his efforts on Scipy
I'll write a separate post on that asap.
and I will be cutting back on my work on Numpy.
I sincerely hope you don't cut back on your work too much Charles. You have done an excellent job as "chief maintainer" over the last years.
The 1.7 release looks to be delayed and I suspect that the Continuum Analytics folks will become increasingly dedicated to the big data push. We need new people to carry things forward and I think Nathaniel can pick up part of the load.
Assuming he wants them, I am definitely +1 on giving Nathaniel commit rights. His recent patches and debugging of issues were of high quality and very helpful.
OK, I went ahead and added him whether he wants it or not ;)
Hah. Thanks! Is there a "committers guide" anywhere? By default I would assume that the rules are pretty much -- continue sending pull requests for my own changes (unless a trivial typo fix in a comment or something), go ahead and merge anyone else's pull request where things seem okay and my best judgement is we have consensus, fix things if my judgement was wrong? But I don't want to step on any toes... -n
On Tue, Jun 5, 2012 at 10:25 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Tue, Jun 5, 2012 at 4:19 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Jun 3, 2012 at 12:04 PM, Ralf Gommers <
wrote:
On Sun, Jun 3, 2012 at 6:43 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
Numpy is approaching a time of transition. Ralf will be concentrating
his
efforts on Scipy
I'll write a separate post on that asap.
and I will be cutting back on my work on Numpy.
I sincerely hope you don't cut back on your work too much Charles. You have done an excellent job as "chief maintainer" over the last years.
The 1.7 release looks to be delayed and I suspect that the Continuum Analytics folks will become increasingly dedicated to the big data
ralf.gommers@googlemail.com> push. We
need new people to carry things forward and I think Nathaniel can pick up part of the load.
Assuming he wants them, I am definitely +1 on giving Nathaniel commit rights. His recent patches and debugging of issues were of high quality and very helpful.
OK, I went ahead and added him whether he wants it or not ;)
Hah. Thanks!
Is there a "committers guide" anywhere? By default I would assume that the rules are pretty much -- continue sending pull requests for my own changes (unless a trivial typo fix in a comment or something), go ahead and merge anyone else's pull request where things seem okay and my best judgement is we have consensus, fix things if my judgement was wrong? But I don't want to step on any toes...
You can commit your own stuff also if someone signs off on it or it seems uncontroversial and has sat there for a while. It's mostly a judgement call. For the commits themselves, the github button doesn't do fast forward or whitespace cleanup, so I have the following alias in .git/config getpatch = !sh -c 'git co -b pull-$1 master &&\ curl https://github.com/numpy/nump/pull/$1.patch|\ git am -3 --whitespace=strip' - which opens a new branch pull-nnn and is useful for the bigger commits so they can be tested and then merged with master before pushing. The non-trivial commits should be tested with at least Python 2.4, 2.7, and 3.2. I also suggest running the one-file build for changes in core since most developers do the separate file thing and sometimes fail to catch single file build problems. Keep an eye on coding style, otherwise it will drift. Chuck
On Tue, Jun 5, 2012 at 11:52 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Tue, Jun 5, 2012 at 10:25 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Tue, Jun 5, 2012 at 4:19 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Jun 3, 2012 at 12:04 PM, Ralf Gommers <
wrote:
On Sun, Jun 3, 2012 at 6:43 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
Numpy is approaching a time of transition. Ralf will be concentrating
his
efforts on Scipy
I'll write a separate post on that asap.
and I will be cutting back on my work on Numpy.
I sincerely hope you don't cut back on your work too much Charles. You have done an excellent job as "chief maintainer" over the last years.
The 1.7 release looks to be delayed and I suspect that the Continuum Analytics folks will become increasingly dedicated to the big data
need new people to carry things forward and I think Nathaniel can
ralf.gommers@googlemail.com> push. We pick up
part of the load.
Assuming he wants them, I am definitely +1 on giving Nathaniel commit rights. His recent patches and debugging of issues were of high quality and very helpful.
OK, I went ahead and added him whether he wants it or not ;)
Hah. Thanks!
Is there a "committers guide" anywhere? By default I would assume that the rules are pretty much -- continue sending pull requests for my own changes (unless a trivial typo fix in a comment or something), go ahead and merge anyone else's pull request where things seem okay and my best judgement is we have consensus, fix things if my judgement was wrong? But I don't want to step on any toes...
You can commit your own stuff also if someone signs off on it or it seems uncontroversial and has sat there for a while. It's mostly a judgement call.
For the commits themselves, the github button doesn't do fast forward or whitespace cleanup, so I have the following alias in .git/config
getpatch = !sh -c 'git co -b pull-$1 master &&\ curl https://github.com/numpy/nump/pull/$1.patch|\ git am -3 --whitespace=strip' -
which opens a new branch pull-nnn and is useful for the bigger commits so they can be tested and then merged with master before pushing. The non-trivial commits should be tested with at least Python 2.4, 2.7, and 3.2. I also suggest running the one-file build for changes in core since most developers do the separate file thing and sometimes fail to catch single file build problems.
Keep an eye on coding style, otherwise it will drift.
And keep in mind that part of your job is to train new committers and help bring them up to speed. See yourself as a recruiter as well as a reviewer. Chuck
On Tue, Jun 5, 2012 at 6:52 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Tue, Jun 5, 2012 at 10:25 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Tue, Jun 5, 2012 at 4:19 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Jun 3, 2012 at 12:04 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Sun, Jun 3, 2012 at 6:43 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
Numpy is approaching a time of transition. Ralf will be concentrating his efforts on Scipy
I'll write a separate post on that asap.
and I will be cutting back on my work on Numpy.
I sincerely hope you don't cut back on your work too much Charles. You have done an excellent job as "chief maintainer" over the last years.
The 1.7 release looks to be delayed and I suspect that the Continuum Analytics folks will become increasingly dedicated to the big data push. We need new people to carry things forward and I think Nathaniel can pick up part of the load.
Assuming he wants them, I am definitely +1 on giving Nathaniel commit rights. His recent patches and debugging of issues were of high quality and very helpful.
OK, I went ahead and added him whether he wants it or not ;)
Hah. Thanks!
Is there a "committers guide" anywhere? By default I would assume that the rules are pretty much -- continue sending pull requests for my own changes (unless a trivial typo fix in a comment or something), go ahead and merge anyone else's pull request where things seem okay and my best judgement is we have consensus, fix things if my judgement was wrong? But I don't want to step on any toes...
You can commit your own stuff also if someone signs off on it or it seems uncontroversial and has sat there for a while. It's mostly a judgement call.
Speaking of which, this pull request has been sitting for a bit, waiting for your input :-) https://github.com/numpy/numpy/pull/280
For the commits themselves, the github button doesn't do fast forward or whitespace cleanup, so I have the following alias in .git/config
getpatch = !sh -c 'git co -b pull-$1 master &&\ curl https://github.com/numpy/nump/pull/$1.patch|\ git am -3 --whitespace=strip' -
which opens a new branch pull-nnn and is useful for the bigger commits so they can be tested and then merged with master before pushing. The non-trivial commits should be tested with at least Python 2.4, 2.7, and 3.2. I also suggest running the one-file build for changes in core since most developers do the separate file thing and sometimes fail to catch single file build problems.
Oops, heh. I don't know how to do the separate file thing, I've just been running single-file builds :-).
Keep an eye on coding style, otherwise it will drift.
Thanks! -n
On Tue, Jun 5, 2012 at 1:14 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Tue, Jun 5, 2012 at 6:52 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Tue, Jun 5, 2012 at 10:25 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Tue, Jun 5, 2012 at 4:19 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Jun 3, 2012 at 12:04 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Sun, Jun 3, 2012 at 6:43 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
Numpy is approaching a time of transition. Ralf will be
his efforts on Scipy
I'll write a separate post on that asap.
and I will be cutting back on my work on Numpy.
I sincerely hope you don't cut back on your work too much Charles. You have done an excellent job as "chief maintainer" over the last years.
The 1.7 release looks to be delayed and I suspect that the Continuum Analytics folks will become increasingly dedicated to the big data push. We need new people to carry things forward and I think Nathaniel can
concentrating pick
up part of the load.
Assuming he wants them, I am definitely +1 on giving Nathaniel commit rights. His recent patches and debugging of issues were of high quality and very helpful.
OK, I went ahead and added him whether he wants it or not ;)
Hah. Thanks!
Is there a "committers guide" anywhere? By default I would assume that the rules are pretty much -- continue sending pull requests for my own changes (unless a trivial typo fix in a comment or something), go ahead and merge anyone else's pull request where things seem okay and my best judgement is we have consensus, fix things if my judgement was wrong? But I don't want to step on any toes...
You can commit your own stuff also if someone signs off on it or it seems uncontroversial and has sat there for a while. It's mostly a judgement call.
Speaking of which, this pull request has been sitting for a bit, waiting for your input :-) https://github.com/numpy/numpy/pull/280
Mark and Travis made most of the comments so I figured it was up to them to sign off. If you think it is ready, go ahead and commit it, it's one of the reasons I gave you the premissions. Chuck
A couple of notes from the IPython workflow in case it's of use to you guys: On Tue, Jun 5, 2012 at 10:52 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
For the commits themselves, the github button doesn't do fast forward or whitespace cleanup, so I have the following alias in .git/config
getpatch = !sh -c 'git co -b pull-$1 master &&\ curl https://github.com/numpy/nump/pull/$1.patch|\ git am -3 --whitespace=strip' -
which opens a new branch pull-nnn and is useful for the bigger commits so they can be tested and then merged with master before pushing. The non-trivial commits should be tested with at least Python 2.4, 2.7, and 3.2. I also suggest running the one-file build for changes in core since most developers do the separate file thing and sometimes fail to catch single file build problems.
1) We've settled on using the green button rather than something like the above, because we decided that having the no-ff was actually a *good* thing (and yes, this reverses my initial opinion on the matter). The reasoning that convinced me was that the merge commit in itself is signal, not noise: - it indicates who did the final reviewing and merging (which doesn't happen in a ff merge b/c there's no separate merge commit) - it serves as a good place to cleanly summarize the PR itself, which could possibly contain many commits. It's the job and responsibility of the person doing the merge to understand the PR enough to explain it succinctly, so that one can read just that message and get a realistic idea of what the say 100 commits that went in were meant to do. These merge commits are the right thing to read when building release notes, instead of having to slog through the individual commits. - this way, the DAG's topology immediately shows what went in with review and what was committed without review (hopefully only small/trivial/emergency fixes). - even if the PR has a single commit, it's still OK to do this, as it marks the reviewer (and credits the reviewer as well, which is actual work). For all these reasons, I'm very happy that we reversed our policy and now *only* use the green button to merge, and *never* do a FF merge. We only commit directly to master in the case of absolutely trivial typo fixes or emergency 'my god master is borked' scenarios. 2) I'd encourage you to steal/improve our 'test_pr / post_pr_test' as well as git-mrb tools: https://github.com/ipython/ipython/blob/master/tools/test_pr.py https://github.com/ipython/ipython/blob/master/tools/post_pr_test.py https://github.com/ipython/ipython/blob/master/tools/git-mrb In particular test_pr is a *huge* help. We now almost never merge something that doesn't have a test_pr report. Here's an example where test_pr revealed initially problems, later fixed: https://github.com/ipython/ipython/pull/1847 Once the fix was confirmed, it was easy to merge. It routinely catches python3 errors we put in because most of the core devs don't use python3 regularly. But now I'm not worried about it anymore, as I know the problems will be caught before merging (I used to feel guilty for constantly breaking py3 and having poor Thomas Kluyver have to clean up my messes). Cheers, f
On Tue, Jun 5, 2012 at 4:59 PM, Fernando Perez <fperez.net@gmail.com> wrote:
A couple of notes from the IPython workflow in case it's of use to you guys:
On Tue, Jun 5, 2012 at 10:52 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
For the commits themselves, the github button doesn't do fast forward or whitespace cleanup, so I have the following alias in .git/config
getpatch = !sh -c 'git co -b pull-$1 master &&\ curl https://github.com/numpy/nump/pull/$1.patch|\ git am -3 --whitespace=strip' -
which opens a new branch pull-nnn and is useful for the bigger commits so they can be tested and then merged with master before pushing. The non-trivial commits should be tested with at least Python 2.4, 2.7, and
3.2.
I also suggest running the one-file build for changes in core since most developers do the separate file thing and sometimes fail to catch single file build problems.
1) We've settled on using the green button rather than something like the above, because we decided that having the no-ff was actually a *good* thing (and yes, this reverses my initial opinion on the matter). The reasoning that convinced me was that the merge commit in itself is signal, not noise:
- it indicates who did the final reviewing and merging (which doesn't happen in a ff merge b/c there's no separate merge commit)
- it serves as a good place to cleanly summarize the PR itself, which could possibly contain many commits. It's the job and responsibility of the person doing the merge to understand the PR enough to explain it succinctly, so that one can read just that message and get a realistic idea of what the say 100 commits that went in were meant to do. These merge commits are the right thing to read when building release notes, instead of having to slog through the individual commits.
- this way, the DAG's topology immediately shows what went in with review and what was committed without review (hopefully only small/trivial/emergency fixes).
- even if the PR has a single commit, it's still OK to do this, as it marks the reviewer (and credits the reviewer as well, which is actual work).
For all these reasons, I'm very happy that we reversed our policy and now *only* use the green button to merge, and *never* do a FF merge. We only commit directly to master in the case of absolutely trivial typo fixes or emergency 'my god master is borked' scenarios.
2) I'd encourage you to steal/improve our 'test_pr / post_pr_test' as well as git-mrb tools:
https://github.com/ipython/ipython/blob/master/tools/test_pr.py https://github.com/ipython/ipython/blob/master/tools/post_pr_test.py https://github.com/ipython/ipython/blob/master/tools/git-mrb
In particular test_pr is a *huge* help. We now almost never merge something that doesn't have a test_pr report. Here's an example where test_pr revealed initially problems, later fixed:
https://github.com/ipython/ipython/pull/1847
Once the fix was confirmed, it was easy to merge. It routinely catches python3 errors we put in because most of the core devs don't use python3 regularly. But now I'm not worried about it anymore, as I know the problems will be caught before merging (I used to feel guilty for constantly breaking py3 and having poor Thomas Kluyver have to clean up my messes).
There are other advantages to pulling down the patch. Fixups can be merged together, commit comments enhanced, whitespace removed, style cleanups can be added, tests can be run, and the PR is automatically rebased. I still like fast forward for single commit merges, for larger merges I specify no-ff so that things come in as a well defined chunk. Chuck
On Tue, Jun 5, 2012 at 4:15 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
There are other advantages to pulling down the patch. Fixups can be merged together, commit comments enhanced, whitespace removed, style cleanups can be added, tests can be run, and the PR is automatically rebased. I still like fast forward for single commit merges, for larger merges I specify no-ff so that things come in as a well defined chunk.
Sure, that's a decision each project can take as it prefers: we've taken the approach that the person doing the merge does *not* massage the history as presented in the PR; instead we have submitters fix things up when deemed necessary (and we help them out a bit with git-fu if needed). And for single commit merges, we use the merge commit as topological evidence that there was review, which is very useful when looking retrospectively at the project. But each project must find how it best wants to proceed, I'm only offering our perspective in case any of it is useful for numpy. You guys will cherrypick the pieces that merge cleanly for numpy ;) Cheers, f
participants (4)
-
Charles R Harris -
Fernando Perez -
Nathaniel Smith -
Ralf Gommers