Andrew, Thank you for your comments. I agree it's confusing coming to github at first. I still have to refer to the jargon-file to understand what everything means. There are a lot of unfamiliar terms.
Thank you for your patches. It does imply more work for developers on NumPy, which is why we prefer the github pull request mechanism. But, having patches is better than not having them. Having easy ways to upload a patch somewhere is something to think about with the intended move to github issue tracker. Best, -Travis On Jul 10, 2012, at 2:05 AM, Andrew Dalke wrote: > On Jul 8, 2012, at 9:22 AM, Scott Sinclair wrote: >> On 6 July 2012 15:48, Andrew Dalke <da...@dalkescientific.com> wrote: >>> I followed the instructions at >>> http://docs.scipy.org/doc/numpy/dev/gitwash/patching.html >>> and added Ticket #2181 (with patch) ... >> >> Those instructions need to be updated to reflect the current preferred >> practice. You'll make code review easier and increase the chances of >> getting your patch accepted by submitting the patch as a Github pull >> request instead (see >> http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html >> for a how-to). It's not very much extra work. > > Both of those URLs point to related documentation under the same > root, so I assumed that both are equally valid. The 'patching' one I > linked to says: > > Making a patch is the simplest and quickest, but if you’re going to be > doing anything more than simple quick things, please consider following > the Git for development model instead. > > That really fits me the best, because I don't know git or github, and > I don't plan to get involved in numpy development other than two patches > (one already posted, and the other, after my holiday, to get rid of > required the numpy.testing import). > > I did look at the development_workflow documentation, and am already > bewildered by the terms 'rebase','fast-foward' etc. It seems to that > last week I made a mistake because I did a "git pull" on my local copy > (which is what I do with Mercurial to get the current trunk code) > instead of: > > git fetch followed by gitrebase, git merge --ff-only or > git merge --no-ff, depending on what you intend. > > I don't know if I made a "common mistake", and I don't know "what [I] > intend." > > I realize that for someone who plans to be a long term contributor, > understanding git, github, and the NumPy development model is > "not very much extra work", but in terms of extra work for me, > or at least minimizing my level of confusion, I would rather do > what the documentation suggests and continue with the submitted > patch. > > Andrew > da...@dalkescientific.com > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
