spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Cutler <cutl...@gmail.com>
Subject Re: [DISCUSS] New sections in Github Pull Request description template
Date Fri, 26 Jul 2019 18:32:09 GMT
The k8s template is pretty good. Under the behavior change section, it
would be good to add instructions to also describe previous and new
behavior as Hyukjin proposed.

On Tue, Jul 23, 2019 at 10:07 PM Reynold Xin <rxin@apache.org> wrote:

> I like the spirit, but not sure about the exact proposal. Take a look at
> k8s':
> https://raw.githubusercontent.com/kubernetes/kubernetes/master/.github/PULL_REQUEST_TEMPLATE.md
>
>
>
> On Tue, Jul 23, 2019 at 8:27 PM, Hyukjin Kwon <gurwls223@gmail.com> wrote:
>
>> (Plus, it helps to track history too. Spark's commit logs are growing and
>> now it's pretty difficult to track the history and see what change
>> introduced a specific behaviour)
>>
>> 2019년 7월 24일 (수) 오후 12:20, Hyukjin Kwon <gurwls223@gmail.com>님이
작성:
>>
>> Hi all,
>>
>> I would like to discuss about some new sections under "## What changes
>> were proposed in this pull request?":
>>
>> ### Do the changes affect _any_ user/dev-facing input or output?
>>
>> (Please answer yes or no. If yes, answer the questions below)
>>
>> ### What was the previous behavior?
>>
>> (Please provide the console output, description and/or reproducer about the previous
behavior)
>>
>> ### What is the behavior the changes propose?
>>
>> (Please provide the console output, description and/or reproducer about the behavior
the changes propose)
>>
>> See
>> https://github.com/apache/spark/blob/master/.github/PULL_REQUEST_TEMPLATE
>>  .
>>
>> From my experience so far in Spark community, and assuming from the
>> interaction with other
>> committers and contributors, It is pretty critical to know before/after
>> behaviour changes even if it
>> was a bug. In addition, I think this is requested by reviewers often.
>>
>> The new sections will make review process much easier, and we're able to
>> quickly judge how serious the changes are.
>> Given that Spark community still suffer from open PRs just queueing up
>> without review, I think this can help
>> both reviewers and PR authors.
>>
>> I do describe them often when I think it's useful and possible.
>> For instance see https://github.com/apache/spark/pull/24927 - I am sure
>> you guys have clear idea what the
>> PR fixes.
>>
>> I cc'ed some guys I can currently think of for now FYI. Please let me
>> know if you guys have any thought on this!
>>
>>
>

Mime
View raw message