You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@dolphinscheduler.apache.org by Yichao Yang <10...@qq.com> on 2020/07/09 04:04:01 UTC
回复：RE：[Vote] Pull Request Title Specification
Hi,
Thank you very much for your two suggestions. According to some normative practices of other communities, I have made corresponding replies in the previous mailing list [1]. You can see if it can solve this problem.
I replied in the mailing list [1] about the benefits and necessity of one-to-one PR and issue. Now I try to understand what you said about the scenario of one PR to many issues. If my understanding is wrong, please point out:
I think that the scenario of one PR to many issues are relatively few, and from the root cause, there are scenarios in which multiple issues need to do the same thing. I think there are two solutions to this scenario: the first is to merge multiple issues with the same function into the same issue, and then close other issues. The second is that multiple issues are basically doing one function, but there are some differences. In this way, the responsibilities of each issue should be clearly divided. The type of each issue supposed to be marked as sub task [2], and then these sub task type issues are associated with one issue. When submitting pr, each PR is only targeted at one Issue of sub task.
I mainly refer to the PR specification of Apache Flink community. If you are interested, please refer to the PR [3] of Apache Flink Community.
If my understanding is not correct, or if you have different opinions, please put forward your understanding of the scenario that a PR corresponds to multiple issues.
If there are no other comments, I will send another email about the specifications between the Committer, the contributor and the issue.
---------------------------------
非常感谢你所提出的这两个问题，我根据其他社区的一些规范实践，在之前的邮件列表 [1] 中已经做了相应的回复，你可以看下是否能解决你说的这个问题。
我在邮件列表 [1] 中回复了关于 pr 和 issue 一对一的好处和必要性，我现在尝试理解下你所说的 pr 和 issue 一对多的场景，如果理解有误，请指出：
我理解 pr 和 issue 一对多的场景首先是比较少的，并且从 pr 和 issue 一对多的根本原因，也就是出现了多个 issue 需要做大体相同的一件事情的场景，那么我认为正对这种场景有两种解法：第一种就是把多个功能相同的 issue 合并到同一个 issue 上，然后把其他的 issue 进行关闭；第二种就是多个 issue 大体上是在做一个功能，但是存在一些细微的差别，这样的话可以把每个 issue 的职责划分清楚，每一个 issue 的类型都标记为 Sub-Task [2]，然后将这些 Sub-Task 类型的 issue 关联到一个总的 issue 上，在提交 pr 时，每个 pr 都只针对一个 Sub-Task 的 issue。
我是主要参考了 Apache Flink Community 的 pr 规范，如果感兴趣的话，可以参考下 Apache Flink Community 的 pr [3]。
如果理解不正确，或者有不同意见的话，敬请提出你对于一个 pr 对应多个 issue 的所理解的场景。
如果没有其他意见的话，之后我会再发一个关于 committer 和 contributor 与 issue 之间的相关规范的邮件。
[1] https://lists.apache.org/thread.html/rd5cf6f2cb3cd5e20b26a55b2fd64a4944ddca7b30307c64cab020862%40%3Cdev.dolphinscheduler.apache.org%3E
[2] https://github.com/apache/incubator-dolphinscheduler-website/pull/147
[3] https://github.com/apache/flink/pulls?q=is%3Apr+is%3Aclosed+is%3Amerged
Best,
Yichao Yang
------------------ 原始邮件 ------------------
发件人: "Jave-Chen"<kejia.chen@foxmail.com>;
发送时间: 2020年7月9日(星期四) 上午7:29
收件人: "dev"<dev@dolphinscheduler.apache.org>;
主题: RE：[Vote] Pull Request Title Specification
On one hand, since everyone is free to create issues,&nbsp;different users may create&nbsp;
issues for the same reason.
On the other hand,&nbsp;spliting a large PR into&nbsp;multiple small PRs requires developers&nbsp;
to read all prs, would it be inappropriate ？
------------------&nbsp;原始邮件&nbsp;------------------
发件人:&nbsp;"CalvinKirs"<acm_master@163.com&gt;;
发送时间:&nbsp;2020年7月9日(星期四) 凌晨2:02
收件人:&nbsp;"dev@dolphinscheduler.apache.org"<dev@dolphinscheduler.apache.org&gt;;
主题:&nbsp;Re:[Vote] Pull Request Title Specification
Hi, I think this is a question worthy of recognition.&nbsp; I think our big pr should be separated, corresponding to an isuess, if it cannot be split, can it be aggregated into an isuess，how do you think？If I am wrong, please correct me
Best regards！
CalvinKirs
On 07/8/2020 22:22，Jave-Chen<kejia.chen@foxmail.com&gt; wrote：
A PR may be associated with multiple issues, so writing Issue No. in PR titile may&amp;nbsp;
be miscellaneous.
------------------&amp;nbsp;原始邮件&amp;nbsp;------------------
发件人:&amp;nbsp;"Yichao Yang"<1048262223@qq.com&amp;gt;;
发送时间:&amp;nbsp;2020年7月8日(星期三) 晚上9:29
收件人:&amp;nbsp;"dev"<dev@dolphinscheduler.apache.org&amp;gt;;
主题:&amp;nbsp;[Vote] Pull Request Title Specification
Hi all,
After referring to the practices of other open source communities on the title of pull request, we propose two pre selection schemes for dolphin scheduler.
First：
Specification:
[`Open Source Project Name`-`Issue No`][`Module Name`] `Pull Request Description`
example：
[DS-3333][server] Fix the xxx exception
[DS-3333][server] Implement xxx
...
Second：
Specification:
[`Pull Request Type`-`Issue No`][`Module Name`] `Pull Request Description`
example：
[Fix-3333][server] Fix the xxx exception
[Feature-3333][server] Implement xxx
...
The Pull Request type is shown in the screenshot in [1].
If you agree with the first one as the title of the pull request, reply 1, and the second one reply 2. If there is no other suggestions after 7 days, we will choose the first one.
--------------------------------------------------------
目前参考了其他开源社区的对于 Pull Request 标题的实践之后，针对 DolphinScheduler 我们提出了两种预选的方案：
第一种：
Specification:
[`Open Source Project Name`-`Issue No`][`Module Name`] `Pull Request Description`
example：
[DS-3333][server] Fix the xxx exception
[DS-3333][server] Implement xxx
...
第二种：
Specification:
[`Pull Request Type`-`Issue No`][`Module Name`] `Pull Request Description`
example：
[Fix-3333][server] Fix the xxx exception
[Feature-3333][server] Implement xxx
...
Pull Request Type 类型在 [1] 中截图给出。
如果想选第一种作为Pull request 标题，则回复1，第二种则回复2。没有其他意见或者建议的话，7天之后默认以第一种作为 Pull Request 规范。
[1] Pull Request Type: https://github.com/apache/incubator-dolphinscheduler-website/pull/147
Best,
Yichao Yang
Re: RE：[Vote] Pull Request Title Specification
Posted by lidong dai <da...@gmail.com>.
2
good job
Best Regards
---------------
DolphinScheduler(Incubator) PPMC
Lidong Dai 代立冬
dailidong66@gmail.com
---------------
Yichao Yang <10...@qq.com> 于2020年7月9日周四 下午12:04写道：
> Hi,
>
>
> Thank you very much for your two suggestions. According to some normative
> practices of other communities, I have made corresponding replies in the
> previous mailing list [1]. You can see if it can solve this problem.
>
>
> I replied in the mailing list [1] about the benefits and necessity of
> one-to-one PR and issue. Now I try to understand what you said about the
> scenario of one PR to many issues. If my understanding is wrong,
> please point out:
>
>
> I think that the scenario of one PR to many issues are
> relatively few, and from the root cause, there are scenarios in which
> multiple issues need to do the same thing. I think there are two solutions
> to this scenario: the first is to merge multiple issues with the same
> function into the same issue, and then close other issues. The second is
> that multiple issues are basically doing one function, but there are some
> differences. In this way, the responsibilities of each issue should be
> clearly divided. The type of each issue supposed to be marked as sub task
> [2], and then these sub task type issues are associated with one issue.
> When submitting pr, each PR is only targeted at one Issue of sub task.
>
>
> I mainly refer to the PR specification of Apache Flink community. If you
> are interested, please refer to the PR [3] of Apache Flink Community.
>
>
> If my understanding is not correct, or if you have different opinions,
> please put forward your understanding of the scenario that a PR corresponds
> to multiple issues.
>
>
> If there are no other comments, I will send another email about the
> specifications between the Committer, the contributor and the issue.
>
>
>
> ---------------------------------
>
>
> 非常感谢你所提出的这两个问题，我根据其他社区的一些规范实践，在之前的邮件列表 [1] 中已经做了相应的回复，你可以看下是否能解决你说的这个问题。
>
>
> 我在邮件列表 [1] 中回复了关于 pr 和 issue 一对一的好处和必要性，我现在尝试理解下你所说的 pr 和 issue
> 一对多的场景，如果理解有误，请指出：
> 我理解 pr 和 issue 一对多的场景首先是比较少的，并且从 pr 和 issue 一对多的根本原因，也就是出现了多个 issue
> 需要做大体相同的一件事情的场景，那么我认为正对这种场景有两种解法：第一种就是把多个功能相同的 issue 合并到同一个 issue 上，然后把其他的
> issue 进行关闭；第二种就是多个 issue 大体上是在做一个功能，但是存在一些细微的差别，这样的话可以把每个 issue 的职责划分清楚，每一个
> issue 的类型都标记为 Sub-Task [2]，然后将这些 Sub-Task 类型的 issue 关联到一个总的 issue 上，在提交 pr
> 时，每个 pr 都只针对一个 Sub-Task 的 issue。
> 我是主要参考了 Apache Flink Community 的 pr 规范，如果感兴趣的话，可以参考下 Apache Flink
> Community 的 pr [3]。
> 如果理解不正确，或者有不同意见的话，敬请提出你对于一个 pr 对应多个 issue 的所理解的场景。
> 如果没有其他意见的话，之后我会再发一个关于 committer 和 contributor 与 issue 之间的相关规范的邮件。
>
>
> [1]
> https://lists.apache.org/thread.html/rd5cf6f2cb3cd5e20b26a55b2fd64a4944ddca7b30307c64cab020862%40%3Cdev.dolphinscheduler.apache.org%3E
> [2] https://github.com/apache/incubator-dolphinscheduler-website/pull/147
> [3]
> https://github.com/apache/flink/pulls?q=is%3Apr+is%3Aclosed+is%3Amerged
>
>
> Best,
> Yichao Yang
>
>
>
>
> ------------------ 原始邮件 ------------------
> 发件人: "Jave-Chen"<kejia.chen@foxmail.com>;
> 发送时间: 2020年7月9日(星期四) 上午7:29
> 收件人: "dev"<dev@dolphinscheduler.apache.org>;
>
> 主题: RE：[Vote] Pull Request Title Specification
>
>
>
> On one hand, since everyone is free to create issues,&nbsp;different
> users may create&nbsp;
> issues for the same reason.
>
>
>
> On the other hand,&nbsp;spliting a large PR into&nbsp;multiple
> small PRs requires developers&nbsp;
> to read all prs, would it be inappropriate ？
>
>
>
>
> ------------------&nbsp;原始邮件&nbsp;------------------
> 发件人:&nbsp;"CalvinKirs"<acm_master@163.com&gt;;
> 发送时间:&nbsp;2020年7月9日(星期四) 凌晨2:02
> 收件人:&nbsp;"dev@dolphinscheduler.apache.org"<
> dev@dolphinscheduler.apache.org&gt;;
>
> 主题:&nbsp;Re:[Vote] Pull Request Title Specification
>
>
>
> Hi, I think this is a question worthy of recognition.&nbsp; I think
> our big pr should be separated, corresponding to an isuess, if it cannot be
> split, can it be aggregated into an isuess，how do you think？If I am wrong,
> please correct me
>
>
> Best regards！
> CalvinKirs
>
>
> On 07/8/2020 22:22，Jave-Chen<kejia.chen@foxmail.com&gt; wrote：
> A PR may be associated with multiple issues, so writing Issue No. in PR
> titile may&amp;nbsp;
> be miscellaneous.
>
>
>
> ------------------&amp;nbsp;原始邮件&amp;nbsp;------------------
> 发件人:&amp;nbsp;"Yichao Yang"<1048262223@qq.com&amp;gt;;
> 发送时间:&amp;nbsp;2020年7月8日(星期三) 晚上9:29
> 收件人:&amp;nbsp;"dev"<dev@dolphinscheduler.apache.org&amp;gt;;
>
> 主题:&amp;nbsp;[Vote] Pull Request Title Specification
>
>
>
> Hi all,
>
>
> After referring to the practices of other open source communities on the
> title of pull request, we propose two pre selection schemes for dolphin
> scheduler.
>
>
> First：
>
> Specification:
>
> [`Open Source Project Name`-`Issue No`][`Module Name`] `Pull Request
> Description`
>
> example：
>
> [DS-3333][server] Fix the xxx exception
>
> [DS-3333][server] Implement xxx
>
> ...
>
>
>
>
> Second：
>
> Specification:
>
> [`Pull Request Type`-`Issue No`][`Module Name`] `Pull Request Description`
>
> example：
>
> [Fix-3333][server] Fix the xxx exception
>
> [Feature-3333][server] Implement xxx
>
> ...
>
> The Pull Request type is shown in the screenshot in [1].
>
>
>
>
> If you agree with the first one as the title of the pull request, reply 1,
> and the second one reply 2. If there is no other suggestions after 7 days,
> we will choose the first one.
>
>
>
>
> --------------------------------------------------------
>
>
>
>
> 目前参考了其他开源社区的对于 Pull Request 标题的实践之后，针对 DolphinScheduler 我们提出了两种预选的方案：
>
>
> 第一种：
>
> Specification:
>
> [`Open Source Project Name`-`Issue No`][`Module Name`] `Pull Request
> Description`
>
> example：
>
> [DS-3333][server] Fix the xxx exception
>
> [DS-3333][server] Implement xxx
>
> ...
>
>
>
>
> 第二种：
>
> Specification:
>
> [`Pull Request Type`-`Issue No`][`Module Name`] `Pull Request Description`
>
> example：
>
> [Fix-3333][server] Fix the xxx exception
>
> [Feature-3333][server] Implement xxx
>
> ...
>
> Pull Request Type 类型在 [1] 中截图给出。
>
>
>
>
> 如果想选第一种作为Pull request 标题，则回复1，第二种则回复2。没有其他意见或者建议的话，7天之后默认以第一种作为 Pull
> Request 规范。
>
>
>
>
> [1] Pull Request Type:
> https://github.com/apache/incubator-dolphinscheduler-website/pull/147
>
>
>
>
> Best,
>
> Yichao Yang