Thanks for the insight Jim. Personally, I have found pull requests much easier to deal with than patches. Of course, I've been doing so many because of GCI that I've worked out something of a system for it. Also, I've found myself getting a little bit frustrated by ordinary patches. This might be because I'm not nearly familiar enough with the git patch format or the relevant git commands. I suspect if I practiced it more, I would be better and faster at it, but right now it just doesn't work for me and I stick with the pull requests.
Of course, I think I still have a lot to learn about how to do pull requests better and more efficiently, but that's another issue entirely. Github does seem to provide a facility to download pull requests as patches, so that seems like a nice medium. If you look in the directions on the bottom of the pull request time you'll see there is a command to use curl to download the complete text of the patch. I suspect that could easily be done in a brower or through other means. This seems like a nice medium while we are working out all the details of our new process flow. What I don't think I want to see is for us to be completely limited to a single mechanism for accepting contributions. Clicking the big "Pull Request" button is so easy for new contributors, while applying raw patches seems to be much more familiar to some of our more experienced contributors. Creating some kind of documentation for committers to talk about how to accept contributions in various forms might be a very good task to do soon. The more information we all have, the better off we will be as a community. --Andrew Whitworth On Tue, Nov 30, 2010 at 7:16 AM, James E Keenan <[email protected]> wrote: > In recent weeks, I've begun to receive many 'git pull' requests. Some of > these relate to code which is now being developed outside the main Parrot > repository (https://github.com/parrot/parrot). Example: We extracted PIRC > from our main repository and placed it in its own. > > Others of these requests, however, pertain to code which could just as > easily be submitted in the form of (a) attachments to post to this list, (b) > attachments to Trac tickets, or (c) IRC pastes (via tools/dev/nopaste.pl). > Speaking for myself, I find the mechanics of all of these easier to deal > with than 'git pull' requests. Example: Last night I was asked to do a > 'git pull' for a two-line patch. It was easier for me to simply re-type the > code and commit it. > > Since (not for the first time) I am questioning the status of git as the > Greatest Thing in the History of the Universe, I realize I run the risk of > starting a flame war here. However, I seem to recall that pmichaud said > that the Rakudo folks were perfectly happy to accept ordinary patches. > > So, again speaking for myself, I'm going to assign a higher priority to > responding to patches submitted via (a), (b) or (c) above than to 'git pull' > requests. In particular, if I'm interacting with people on #parrot, I can > apply patches submitted via 'nopaste' much more quickly than 'git pull' > requests. > > Thank you very much. > > kid51 > > > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
