2 good job
Best Regards --------------- DolphinScheduler(Incubator) PPMC Lidong Dai 代立冬 [email protected] --------------- Yichao Yang <[email protected]> 于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"<[email protected]>; > 发送时间: 2020年7月9日(星期四) 上午7:29 > 收件人: "dev"<[email protected]>; > > 主题: 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"<[email protected]&gt;; > 发送时间:&nbsp;2020年7月9日(星期四) 凌晨2:02 > 收件人:&nbsp;"[email protected]"< > [email protected]&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<[email protected]&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"<[email protected]&amp;gt;; > 发送时间:&amp;nbsp;2020年7月8日(星期三) 晚上9:29 > 收件人:&amp;nbsp;"dev"<[email protected]&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
