[Yt-dev] pull requests and their awesomeness

[Cameron Hummels]

I totally agree with everything Britton stated.  The key here is to make
it easy for other developers to check/test your work, with the onus of
responsibility placed on the pull request initiator.  I'd love to
discuss this more next week.

Cameron

On 10/07/2011 10:49 AM, Matthew Turk wrote:
> Hi Britton and Sam,
>
> I found the process to be really great.  Jeff has been suggesting for
> a while that we identify different areas in the code, levels of
> severity of changes, and have sets of eyes on changes.  Since a bunch
> of us (although not all of us!) will be in NYC next week, maybe we
> could take an hour or so to try to brainstorm and talk (over pizza,
> drinks, etc?) about pull requests and how we can and should use them?
> It'd be good to walk the line Britton identifies, since we're all busy
> people with lots of work to do, but we also don't want to introduce
> regressions.  Guidelines would help ensure that burden of testing
> changes isn't too high on the wrong people.
>
> -Matt
>
> On Fri, Oct 7, 2011 at 10:21 AM, Britton Smith <brittonsmith at gmail.com> wrote:
>> I think this is a great model for development.  When it comes to submitting
>> large new features or significant invasive changes, the onus must be on the
>> original developer to make inspection and verification of incoming changes
>> as easy as possible for reviewers.  In my opinion, this means pull requests
>> of this nature should be accompanied by full explanation of what the code is
>> doing, how it works, and how a reviewer should know whether it's working or
>> not, including testing scripts.  Otherwise, it's just asking busy people to
>> do more work.
>>
>> For small bug fixes, I think it's enough to submit the pull request and have
>> a few extra pairs of eyes look it over.  For bigger things, I think this is
>> something to keep in mind.
>>
>> Britton
>>
>> On Thu, Oct 6, 2011 at 4:12 PM, Sam Skillman <samskillman at gmail.com> wrote:
>>> Hi all,
>>> I just wanted to relate the experience I just had with Matt's pull request
>>> on the isocontour flux calculations.  If you already regard pull requests as
>>> being awesome, you can probably stop reading.
>>> The situation:
>>> Matt had a fairly large set of changes that added new functionality to yt,
>>> and wanted another pair of eyes before pulling it into the main trunk.
>>> The tool: bitbucket pull requests
>>> Matt developed the changes in his fork of the main yt branch, then
>>> requested that they be pulled into the main repo (even though he had the
>>> ability to push directly).
>>> The benefit:
>>> This allowed me to pull down his changes, test them, iterate back and
>>> forth with him, and make comments that now forever live in the "Accepted
>>> pull requests" part of the repo so that anyone can see why that was changed.
>>>  When it was set to go, I just clicked "Accept" and the changes were all
>>> merged in without incident.
>>> Anyways, very effortless way to handle changes that are more than just one
>>> liners and need a collaborative effort before going into the main branch.
>>> Sam
>>>
>>>
>>> _______________________________________________
>>> Yt-dev mailing list
>>> Yt-dev at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>
>>
>> _______________________________________________
>> Yt-dev mailing list
>> Yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>>
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>

-- 
Cameron Hummels
PhD Candidate, Astronomy Department of Columbia University
Public Outreach Director, Astronomy Department of Columbia University
NASA IYA New York State Student Ambassador
http://outreach.astro.columbia.edu 
PGP: 0x06F886E3