[Yt-dev] pull requests and their awesomeness

[Matthew Turk]

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
>
>