You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pulsar.apache.org by Yu <li...@apache.org> on 2022/08/04 08:12:21 UTC
[Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions
Hi team,
It has been 4 months since we discussed the [Guideline] Pulsar PR Naming
Convention [1].
Nowadays, when reading the PR list [2], you’ll find more and more people
follow and get used to this rule.
It improves collaboration efficiency, that is great!
This makes us think about moving the rule forward, that is, standardizing
PR title naming using GitHub Actions, which is a more efficient way.
So we'd like to start a vote on PIP 198: Standardize PR Naming Convention
using GitHub Actions [3].
This proposal contains:
- Why do this?
- How do this?
- Pre-discussions and other thoughts
Feel free to comment, thank you!
[1] https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
[2] https://github.com/apache/pulsar/pulls
[3]
https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
Yu, Max, mangoGoForward
Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions
Posted by Yu <li...@apache.org>.
Hi team,
This is a continued thread from the last one.
Feel free to vote and comment on this issue, thank you!
~~~~~~~~~~~~~~~~
Vote:
For PR titles, which convention should we follow?
- Angular convention [1]
- Our customized convention (it's customized based on Angular) [2]
~~~~~~~~~~~~~~~~
The differences between Angular and ours are:
1. Definition
1.1 Property
- Angular: [type] is required, [scope] is optional
- Ours: [type] and [scope] are required
1.2 Content
- Angular: ci, test, and docs belong to [type]
- Ours: ci, test, and docs belong to [scope] because I think [type] defines
"what action do you make" (eg. add/delete/update/...), while [scope]
defines "where do you make changes".
2. Punctuation
- Angular: parenthesis and exclaim points are used
- Ours: brackets are used
~~~~~~~~~~~~~~~~
Comparison examples
Taking existing Pulsar PR titles as examples:
Example 1
- Angular:
fix: Filter out already deleted entries again before sending messages to
consumers
- Ours:
[fix][broker] Filter out already deleted entries again before sending
messages to consumers
Example 2
- Angular:
ci: add flaky test issues and PRs to flaky test project
- Ours:
[feat][ci] Add flaky test issues and PRs to flaky test project
Example 3
- Angular:
docs: Document configuration added by PIP-145 doc
- Ours:
[improve][doc] Document configuration added by PIP-145 doc
~~~~~~~~~~~~~~~~
I prefer our customized convention because:
- It makes PR titles more clear and self-explanatory.
- No need to change users' habits since many people in the community have
followed and gotten used to it for several months [3].
~~~~~~~~~~~~~~~~
Thoughts? Thank you!
[1]
https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit-message-header
[2]
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno
[3] https://github.com/apache/pulsar/pulls
On Wed, Aug 10, 2022 at 6:11 PM Yu <li...@apache.org> wrote:
>
> Hi team,
>
> Thanks for all your suggestions!
>
> I'll move PIP 198 forward since we get 3 binding votes (Penghui, Lari,
> Michael).
>
> For the implementation details, I've got many different suggestions, which
> can be summarized into 2 major issues:
>
> - Issue 1: which convention should we follow?
> Angular [1] or our existing one (customized based on Angular) [2]?
>
> - Issue 2: how to define [type] and [scope]?
> For example, abbreviations.
>
> To avoid chaos and personal bias, I'll initiate polls one by one and let
> the community decide.
>
> Once we reach a consensus on issue 1, we can move forward to issue 2.
>
> [1]
> https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit-message-header
> [2]
> https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno
>
> Yu
>
> On Wed, Aug 10, 2022 at 6:05 PM Yu <li...@apache.org> wrote:
>
>> Hi Lari,
>>
>> Thanks for your suggestions! Please see my replies inline.
>>
>> > Would it be possible to improve the proposal in a way that the valid
>> prefixes for type and component are in a file in the repository and the
>> possible checker would use this file as the source of truth?
>>
>> Yes, it's the same as we did previously [1].
>>
>> > I hope we could get rid of the brackets too and simply use a similar
>> format as Angular does.
>>
>> I agree that the PR title should be as much concise as possible, but I
>> prefer our customized convention because:
>>
>> (1) Compared with our current convention (customized based on Angular)
>> [2], seems that Angular only saves one char.
>>
>> For example,
>>
>> - Angular: feat(broker): add xxx → (): occupy 3 chars
>> - Ours: [feat][broker] add xxx → (): occupy 4 chars
>>
>> (2) I agree with Michael. Brackets make info clearer.
>>
>> Yu
>>
>> [1]
>> https://github.com/apache/pulsar/pull/16836/files#diff-30f66e07c98171a7ed7bd1f1f873a2dbfb05da069ec859af82dd6bc05048c2c5
>> [2]
>> https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno
>>
>> On Tue, Aug 9, 2022 at 5:47 PM Lari Hotari <lh...@apache.org> wrote:
>>
>>> +1, with some conditions about the details of PIP 198 that are listed
>>> below:
>>>
>>> Would it be possible to improve the proposal in a way that the valid
>>> prefixes for type and component are in a file in the repository and the
>>> possible checker would use this file as the source of truth? Tison already
>>> pointed out in a Slack discussion that such a GHA exists which uses a yaml
>>> file.
>>>
>>> I also hope that the prefixes are as short as possible since there's a
>>> general recommendation to keep a commit title under 50 characters as I have
>>> explained in
>>> https://lists.apache.org/thread/67fqbo25oq75wrpsq5s4xw9rr55mlbms . I
>>> know it's not a hard limit, but it does harm readability of the commit log
>>> in many tools if prefixes use up a majority of the title length.
>>>
>>> So as long as the prefixes are short and easy, I'm fine with this
>>> proposal.
>>>
>>> I would have hoped that the proposal would have been more like the
>>> Angular commit message format,
>>> https://github.com/angular/angular/blob/main/CONTRIBUTING.md#-commit-message-format
>>> . I like the short prefixes and how the "component" is "scope" and maps to
>>> a npm module.
>>>
>>> In our case, the scope (we are calling this "component") could map
>>> directly to the Maven artifactId by droping the "pulsar-" prefix. That
>>> would prevent making up new names for the components that are different
>>> from existing names.
>>> for example: artifactId: pulsar-broker, use "broker"
>>> artifactId: pulsar-io-kafke, use "io-kafka"
>>> There would be some exceptions in the apache/pulsar repository for the
>>> cpp client. That could be client-cpp (from directory name
>>> "pulsar-client-cpp" by dropping the "pulsar-" prefix).
>>>
>>> Another concern that I had was about duplicating the information with
>>> labels. Tison explained to my that the automation could add the labels
>>> based on the title and the user wouldn't have to add duplicate information
>>> if such a solution exists.
>>>
>>> Summary:
>>> I hope that PIP 198 could be revisited with the proposed way to map the
>>> component name directly from the Maven artifactId. Another request is to
>>> shorten the type (use "feat" instead of "feature", etc.) to save
>>> characters.
>>> I hope we could get rid of the brackets too and simply use a similar
>>> format as Angular does.
>>>
>>> -Lari
>>>
>>> On 2022/08/04 08:12:21 Yu wrote:
>>> > Hi team,
>>> >
>>> > It has been 4 months since we discussed the [Guideline] Pulsar PR
>>> Naming
>>> > Convention [1].
>>> >
>>> > Nowadays, when reading the PR list [2], you’ll find more and more
>>> people
>>> > follow and get used to this rule.
>>> >
>>> > It improves collaboration efficiency, that is great!
>>> >
>>> > This makes us think about moving the rule forward, that is,
>>> standardizing
>>> > PR title naming using GitHub Actions, which is a more efficient way.
>>> >
>>> > So we'd like to start a vote on PIP 198: Standardize PR Naming
>>> Convention
>>> > using GitHub Actions [3].
>>> >
>>> >
>>> > This proposal contains:
>>> >
>>> > - Why do this?
>>> >
>>> > - How do this?
>>> >
>>> > - Pre-discussions and other thoughts
>>> >
>>> > Feel free to comment, thank you!
>>> >
>>> > [1] https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
>>> >
>>> > [2] https://github.com/apache/pulsar/pulls
>>> >
>>> > [3]
>>> >
>>> https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
>>> >
>>> >
>>> > Yu, Max, mangoGoForward
>>> >
>>>
>>
Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions
Posted by Yu <li...@apache.org>.
Hi team,
Thanks for all your suggestions!
I'll move PIP 198 forward since we get 3 binding votes (Penghui, Lari,
Michael).
For the implementation details, I've got many different suggestions, which
can be summarized into 2 major issues:
- Issue 1: which convention should we follow?
Angular [1] or our existing one (customized based on Angular) [2]?
- Issue 2: how to define [type] and [scope]?
For example, abbreviations.
To avoid chaos and personal bias, I'll initiate polls one by one and let
the community decide.
Once we reach a consensus on issue 1, we can move forward to issue 2.
[1]
https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit-message-header
[2]
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno
Yu
On Wed, Aug 10, 2022 at 6:05 PM Yu <li...@apache.org> wrote:
> Hi Lari,
>
> Thanks for your suggestions! Please see my replies inline.
>
> > Would it be possible to improve the proposal in a way that the valid
> prefixes for type and component are in a file in the repository and the
> possible checker would use this file as the source of truth?
>
> Yes, it's the same as we did previously [1].
>
> > I hope we could get rid of the brackets too and simply use a similar
> format as Angular does.
>
> I agree that the PR title should be as much concise as possible, but I
> prefer our customized convention because:
>
> (1) Compared with our current convention (customized based on Angular)
> [2], seems that Angular only saves one char.
>
> For example,
>
> - Angular: feat(broker): add xxx → (): occupy 3 chars
> - Ours: [feat][broker] add xxx → (): occupy 4 chars
>
> (2) I agree with Michael. Brackets make info clearer.
>
> Yu
>
> [1]
> https://github.com/apache/pulsar/pull/16836/files#diff-30f66e07c98171a7ed7bd1f1f873a2dbfb05da069ec859af82dd6bc05048c2c5
> [2]
> https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno
>
> On Tue, Aug 9, 2022 at 5:47 PM Lari Hotari <lh...@apache.org> wrote:
>
>> +1, with some conditions about the details of PIP 198 that are listed
>> below:
>>
>> Would it be possible to improve the proposal in a way that the valid
>> prefixes for type and component are in a file in the repository and the
>> possible checker would use this file as the source of truth? Tison already
>> pointed out in a Slack discussion that such a GHA exists which uses a yaml
>> file.
>>
>> I also hope that the prefixes are as short as possible since there's a
>> general recommendation to keep a commit title under 50 characters as I have
>> explained in
>> https://lists.apache.org/thread/67fqbo25oq75wrpsq5s4xw9rr55mlbms . I
>> know it's not a hard limit, but it does harm readability of the commit log
>> in many tools if prefixes use up a majority of the title length.
>>
>> So as long as the prefixes are short and easy, I'm fine with this
>> proposal.
>>
>> I would have hoped that the proposal would have been more like the
>> Angular commit message format,
>> https://github.com/angular/angular/blob/main/CONTRIBUTING.md#-commit-message-format
>> . I like the short prefixes and how the "component" is "scope" and maps to
>> a npm module.
>>
>> In our case, the scope (we are calling this "component") could map
>> directly to the Maven artifactId by droping the "pulsar-" prefix. That
>> would prevent making up new names for the components that are different
>> from existing names.
>> for example: artifactId: pulsar-broker, use "broker"
>> artifactId: pulsar-io-kafke, use "io-kafka"
>> There would be some exceptions in the apache/pulsar repository for the
>> cpp client. That could be client-cpp (from directory name
>> "pulsar-client-cpp" by dropping the "pulsar-" prefix).
>>
>> Another concern that I had was about duplicating the information with
>> labels. Tison explained to my that the automation could add the labels
>> based on the title and the user wouldn't have to add duplicate information
>> if such a solution exists.
>>
>> Summary:
>> I hope that PIP 198 could be revisited with the proposed way to map the
>> component name directly from the Maven artifactId. Another request is to
>> shorten the type (use "feat" instead of "feature", etc.) to save
>> characters.
>> I hope we could get rid of the brackets too and simply use a similar
>> format as Angular does.
>>
>> -Lari
>>
>> On 2022/08/04 08:12:21 Yu wrote:
>> > Hi team,
>> >
>> > It has been 4 months since we discussed the [Guideline] Pulsar PR Naming
>> > Convention [1].
>> >
>> > Nowadays, when reading the PR list [2], you’ll find more and more people
>> > follow and get used to this rule.
>> >
>> > It improves collaboration efficiency, that is great!
>> >
>> > This makes us think about moving the rule forward, that is,
>> standardizing
>> > PR title naming using GitHub Actions, which is a more efficient way.
>> >
>> > So we'd like to start a vote on PIP 198: Standardize PR Naming
>> Convention
>> > using GitHub Actions [3].
>> >
>> >
>> > This proposal contains:
>> >
>> > - Why do this?
>> >
>> > - How do this?
>> >
>> > - Pre-discussions and other thoughts
>> >
>> > Feel free to comment, thank you!
>> >
>> > [1] https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
>> >
>> > [2] https://github.com/apache/pulsar/pulls
>> >
>> > [3]
>> >
>> https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
>> >
>> >
>> > Yu, Max, mangoGoForward
>> >
>>
>
Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions
Posted by Yu <li...@apache.org>.
Hi Lari,
Thanks for your suggestions! Please see my replies inline.
> Would it be possible to improve the proposal in a way that the valid
prefixes for type and component are in a file in the repository and the
possible checker would use this file as the source of truth?
Yes, it's the same as we did previously [1].
> I hope we could get rid of the brackets too and simply use a similar
format as Angular does.
I agree that the PR title should be as much concise as possible, but I
prefer our customized convention because:
(1) Compared with our current convention (customized based on Angular) [2],
seems that Angular only saves one char.
For example,
- Angular: feat(broker): add xxx → (): occupy 3 chars
- Ours: [feat][broker] add xxx → (): occupy 4 chars
(2) I agree with Michael. Brackets make info clearer.
Yu
[1]
https://github.com/apache/pulsar/pull/16836/files#diff-30f66e07c98171a7ed7bd1f1f873a2dbfb05da069ec859af82dd6bc05048c2c5
[2]
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno
On Tue, Aug 9, 2022 at 5:47 PM Lari Hotari <lh...@apache.org> wrote:
> +1, with some conditions about the details of PIP 198 that are listed
> below:
>
> Would it be possible to improve the proposal in a way that the valid
> prefixes for type and component are in a file in the repository and the
> possible checker would use this file as the source of truth? Tison already
> pointed out in a Slack discussion that such a GHA exists which uses a yaml
> file.
>
> I also hope that the prefixes are as short as possible since there's a
> general recommendation to keep a commit title under 50 characters as I have
> explained in
> https://lists.apache.org/thread/67fqbo25oq75wrpsq5s4xw9rr55mlbms . I know
> it's not a hard limit, but it does harm readability of the commit log in
> many tools if prefixes use up a majority of the title length.
>
> So as long as the prefixes are short and easy, I'm fine with this
> proposal.
>
> I would have hoped that the proposal would have been more like the Angular
> commit message format,
> https://github.com/angular/angular/blob/main/CONTRIBUTING.md#-commit-message-format
> . I like the short prefixes and how the "component" is "scope" and maps to
> a npm module.
>
> In our case, the scope (we are calling this "component") could map
> directly to the Maven artifactId by droping the "pulsar-" prefix. That
> would prevent making up new names for the components that are different
> from existing names.
> for example: artifactId: pulsar-broker, use "broker"
> artifactId: pulsar-io-kafke, use "io-kafka"
> There would be some exceptions in the apache/pulsar repository for the cpp
> client. That could be client-cpp (from directory name "pulsar-client-cpp"
> by dropping the "pulsar-" prefix).
>
> Another concern that I had was about duplicating the information with
> labels. Tison explained to my that the automation could add the labels
> based on the title and the user wouldn't have to add duplicate information
> if such a solution exists.
>
> Summary:
> I hope that PIP 198 could be revisited with the proposed way to map the
> component name directly from the Maven artifactId. Another request is to
> shorten the type (use "feat" instead of "feature", etc.) to save
> characters.
> I hope we could get rid of the brackets too and simply use a similar
> format as Angular does.
>
> -Lari
>
> On 2022/08/04 08:12:21 Yu wrote:
> > Hi team,
> >
> > It has been 4 months since we discussed the [Guideline] Pulsar PR Naming
> > Convention [1].
> >
> > Nowadays, when reading the PR list [2], you’ll find more and more people
> > follow and get used to this rule.
> >
> > It improves collaboration efficiency, that is great!
> >
> > This makes us think about moving the rule forward, that is, standardizing
> > PR title naming using GitHub Actions, which is a more efficient way.
> >
> > So we'd like to start a vote on PIP 198: Standardize PR Naming Convention
> > using GitHub Actions [3].
> >
> >
> > This proposal contains:
> >
> > - Why do this?
> >
> > - How do this?
> >
> > - Pre-discussions and other thoughts
> >
> > Feel free to comment, thank you!
> >
> > [1] https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
> >
> > [2] https://github.com/apache/pulsar/pulls
> >
> > [3]
> >
> https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
> >
> >
> > Yu, Max, mangoGoForward
> >
>
Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions
Posted by Lari Hotari <lh...@apache.org>.
+1, with some conditions about the details of PIP 198 that are listed below:
Would it be possible to improve the proposal in a way that the valid prefixes for type and component are in a file in the repository and the possible checker would use this file as the source of truth? Tison already pointed out in a Slack discussion that such a GHA exists which uses a yaml file.
I also hope that the prefixes are as short as possible since there's a general recommendation to keep a commit title under 50 characters as I have explained in https://lists.apache.org/thread/67fqbo25oq75wrpsq5s4xw9rr55mlbms . I know it's not a hard limit, but it does harm readability of the commit log in many tools if prefixes use up a majority of the title length.
So as long as the prefixes are short and easy, I'm fine with this proposal.
I would have hoped that the proposal would have been more like the Angular commit message format, https://github.com/angular/angular/blob/main/CONTRIBUTING.md#-commit-message-format . I like the short prefixes and how the "component" is "scope" and maps to a npm module.
In our case, the scope (we are calling this "component") could map directly to the Maven artifactId by droping the "pulsar-" prefix. That would prevent making up new names for the components that are different from existing names.
for example: artifactId: pulsar-broker, use "broker"
artifactId: pulsar-io-kafke, use "io-kafka"
There would be some exceptions in the apache/pulsar repository for the cpp client. That could be client-cpp (from directory name "pulsar-client-cpp" by dropping the "pulsar-" prefix).
Another concern that I had was about duplicating the information with labels. Tison explained to my that the automation could add the labels based on the title and the user wouldn't have to add duplicate information if such a solution exists.
Summary:
I hope that PIP 198 could be revisited with the proposed way to map the component name directly from the Maven artifactId. Another request is to shorten the type (use "feat" instead of "feature", etc.) to save characters.
I hope we could get rid of the brackets too and simply use a similar format as Angular does.
-Lari
On 2022/08/04 08:12:21 Yu wrote:
> Hi team,
>
> It has been 4 months since we discussed the [Guideline] Pulsar PR Naming
> Convention [1].
>
> Nowadays, when reading the PR list [2], you’ll find more and more people
> follow and get used to this rule.
>
> It improves collaboration efficiency, that is great!
>
> This makes us think about moving the rule forward, that is, standardizing
> PR title naming using GitHub Actions, which is a more efficient way.
>
> So we'd like to start a vote on PIP 198: Standardize PR Naming Convention
> using GitHub Actions [3].
>
>
> This proposal contains:
>
> - Why do this?
>
> - How do this?
>
> - Pre-discussions and other thoughts
>
> Feel free to comment, thank you!
>
> [1] https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
>
> [2] https://github.com/apache/pulsar/pulls
>
> [3]
> https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
>
>
> Yu, Max, mangoGoForward
>
Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions
Posted by Michael Marshall <mm...@apache.org>.
+1 (binding) to the overall proposal. I also agree with the
clarifications/requests raised by Tison and Lari. I prefer the
abbreviated prefixes, and I think using a GitHub Action to enforce the
formatting would guarantee that the formatting is correct. For
example, when I review PRs and merge them, I often forget to sanitize
the PR title because I am so focused on the PR's content itself, and
once it's committed, it's in the history forever.
> I hope we could get rid of the brackets too and simply use a similar format as Angular does.
I do like the look of brackets :), but I agree that the current format
is more verbose than necessary, and if we want to target < 50 chars,
every char matters.
Thanks,
Michael
On Tue, Aug 9, 2022 at 7:57 AM Anon Hxy <an...@gmail.com> wrote:
>
> +1 (non-binding)
>
> Thanks,
> Xiaoyu Hou
>
> Yu <li...@apache.org> 于2022年8月4日周四 16:13写道：
>
> > Hi team,
> >
> > It has been 4 months since we discussed the [Guideline] Pulsar PR Naming
> > Convention [1].
> >
> > Nowadays, when reading the PR list [2], you’ll find more and more people
> > follow and get used to this rule.
> >
> > It improves collaboration efficiency, that is great!
> >
> > This makes us think about moving the rule forward, that is, standardizing
> > PR title naming using GitHub Actions, which is a more efficient way.
> >
> > So we'd like to start a vote on PIP 198: Standardize PR Naming Convention
> > using GitHub Actions [3].
> >
> >
> > This proposal contains:
> >
> > - Why do this?
> >
> > - How do this?
> >
> > - Pre-discussions and other thoughts
> >
> > Feel free to comment, thank you!
> >
> > [1] https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
> >
> > [2] https://github.com/apache/pulsar/pulls
> >
> > [3]
> >
> > https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
> >
> >
> > Yu, Max, mangoGoForward
> >
Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions
Posted by Anon Hxy <an...@gmail.com>.
+1 (non-binding)
Thanks,
Xiaoyu Hou
Yu <li...@apache.org> 于2022年8月4日周四 16:13写道：
> Hi team,
>
> It has been 4 months since we discussed the [Guideline] Pulsar PR Naming
> Convention [1].
>
> Nowadays, when reading the PR list [2], you’ll find more and more people
> follow and get used to this rule.
>
> It improves collaboration efficiency, that is great!
>
> This makes us think about moving the rule forward, that is, standardizing
> PR title naming using GitHub Actions, which is a more efficient way.
>
> So we'd like to start a vote on PIP 198: Standardize PR Naming Convention
> using GitHub Actions [3].
>
>
> This proposal contains:
>
> - Why do this?
>
> - How do this?
>
> - Pre-discussions and other thoughts
>
> Feel free to comment, thank you!
>
> [1] https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
>
> [2] https://github.com/apache/pulsar/pulls
>
> [3]
>
> https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
>
>
> Yu, Max, mangoGoForward
>
Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions
Posted by Liu Yu <li...@apache.org>.
Hi tison,
Thanks for your suggestions!
> Although, we should later move the standard to our website where the whole project can easily contribute to ...
Sure. I'll move the [Guide] Pulsar Pull Request Naming Convention [1] to a public place where everyone can contribute after we finalize the content. Google doc is only for convenient editing.
[1] https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#heading=h.wu6ygjne8e35
On 2022/08/08 14:06:59 tison wrote:
> +1 (non-binding) to the proposal itself.
>
> Although, we should later move the standard to our website where the whole
> project can easily contribute to and follow the general contribution
> process - that is, send a pull request, review, and merge. I regard current
> gdoc content as a temporary container for this content.
>
> If this proposal gets accepted, @Yu you can create an issue for the dev doc
> part and ping me. I can offer my help to write so.
>
> Best,
> tison.
>
>
> Zike Yang <zi...@apache.org> 于2022年8月8日周一 13:35写道：
>
> > +1 (non-binding)
> >
> > Thanks
> > Zike Yang
> >
> > On Mon, Aug 8, 2022 at 1:06 PM Xiangying Meng <xi...@apache.org>
> > wrote:
> > >
> > > +1(non-binding)
> > >
> > > yours sincerely,
> > > xiangying Meng
> > >
> > > On Thu, Aug 4, 2022 at 4:13 PM Yu <li...@apache.org> wrote:
> > >
> > > > Hi team,
> > > >
> > > > It has been 4 months since we discussed the [Guideline] Pulsar PR
> > Naming
> > > > Convention [1].
> > > >
> > > > Nowadays, when reading the PR list [2], you’ll find more and more
> > people
> > > > follow and get used to this rule.
> > > >
> > > > It improves collaboration efficiency, that is great!
> > > >
> > > > This makes us think about moving the rule forward, that is,
> > standardizing
> > > > PR title naming using GitHub Actions, which is a more efficient way.
> > > >
> > > > So we'd like to start a vote on PIP 198: Standardize PR Naming
> > Convention
> > > > using GitHub Actions [3].
> > > >
> > > >
> > > > This proposal contains:
> > > >
> > > > - Why do this?
> > > >
> > > > - How do this?
> > > >
> > > > - Pre-discussions and other thoughts
> > > >
> > > > Feel free to comment, thank you!
> > > >
> > > > [1] https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
> > > >
> > > > [2] https://github.com/apache/pulsar/pulls
> > > >
> > > > [3]
> > > >
> > > >
> > https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
> > > >
> > > >
> > > > Yu, Max, mangoGoForward
> > > >
> >
>
Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions
Posted by Liu Yu <li...@apache.org>.
Hi tison,
Thanks for your suggestions!
> Currently, I'd suggest: feature -> feat workflow -> ci improve/cleanup -> chore...
I agree on some and will send votes step by step to let the community decide.
On 2022/08/09 09:21:54 tison wrote:
> Hi Yu,
>
> To be clear, the candidates of types and components are a bit long which
> may waste space for meaningful information.
>
> For example, Angular names feature as feat to save letters. GitHub only
> shows the first 50 characters for PR title.
>
> I'd like to confirm that the name of types and components are not voted in
> this thread and postponed when we review the patch.
>
> Currently, I'd suggest:
>
> feature -> feat
> workflow -> ci
> improve/cleanup -> chore
> dependency -> dep
> function -> fn
> security -> sec
> website -> site
> ...
>
> Best,
> tison.
>
>
> Qiang Huang <qi...@gmail.com> 于2022年8月9日周二 15:07写道：
>
> > +1 (non-binding) I like the idea of check PR title as a job.
> > Good job, Yu.
> >
> > tison <wa...@gmail.com> 于2022年8月8日周一 22:07写道：
> >
> > > +1 (non-binding) to the proposal itself.
> > >
> > > Although, we should later move the standard to our website where the
> > whole
> > > project can easily contribute to and follow the general contribution
> > > process - that is, send a pull request, review, and merge. I regard
> > current
> > > gdoc content as a temporary container for this content.
> > >
> > > If this proposal gets accepted, @Yu you can create an issue for the dev
> > doc
> > > part and ping me. I can offer my help to write so.
> > >
> > > Best,
> > > tison.
> > >
> > >
> > > Zike Yang <zi...@apache.org> 于2022年8月8日周一 13:35写道：
> > >
> > > > +1 (non-binding)
> > > >
> > > > Thanks
> > > > Zike Yang
> > > >
> > > > On Mon, Aug 8, 2022 at 1:06 PM Xiangying Meng <xi...@apache.org>
> > > > wrote:
> > > > >
> > > > > +1(non-binding)
> > > > >
> > > > > yours sincerely,
> > > > > xiangying Meng
> > > > >
> > > > > On Thu, Aug 4, 2022 at 4:13 PM Yu <li...@apache.org> wrote:
> > > > >
> > > > > > Hi team,
> > > > > >
> > > > > > It has been 4 months since we discussed the [Guideline] Pulsar PR
> > > > Naming
> > > > > > Convention [1].
> > > > > >
> > > > > > Nowadays, when reading the PR list [2], you’ll find more and more
> > > > people
> > > > > > follow and get used to this rule.
> > > > > >
> > > > > > It improves collaboration efficiency, that is great!
> > > > > >
> > > > > > This makes us think about moving the rule forward, that is,
> > > > standardizing
> > > > > > PR title naming using GitHub Actions, which is a more efficient
> > way.
> > > > > >
> > > > > > So we'd like to start a vote on PIP 198: Standardize PR Naming
> > > > Convention
> > > > > > using GitHub Actions [3].
> > > > > >
> > > > > >
> > > > > > This proposal contains:
> > > > > >
> > > > > > - Why do this?
> > > > > >
> > > > > > - How do this?
> > > > > >
> > > > > > - Pre-discussions and other thoughts
> > > > > >
> > > > > > Feel free to comment, thank you!
> > > > > >
> > > > > > [1]
> > https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
> > > > > >
> > > > > > [2] https://github.com/apache/pulsar/pulls
> > > > > >
> > > > > > [3]
> > > > > >
> > > > > >
> > > >
> > >
> > https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
> > > > > >
> > > > > >
> > > > > > Yu, Max, mangoGoForward
> > > > > >
> > > >
> > >
> >
> >
> > --
> > BR,
> > Qiang Huang
> >
>
Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions
Posted by tison <wa...@gmail.com>.
Hi Yu,
To be clear, the candidates of types and components are a bit long which
may waste space for meaningful information.
For example, Angular names feature as feat to save letters. GitHub only
shows the first 50 characters for PR title.
I'd like to confirm that the name of types and components are not voted in
this thread and postponed when we review the patch.
Currently, I'd suggest:
feature -> feat
workflow -> ci
improve/cleanup -> chore
dependency -> dep
function -> fn
security -> sec
website -> site
...
Best,
tison.
Qiang Huang <qi...@gmail.com> 于2022年8月9日周二 15:07写道：
> +1 (non-binding) I like the idea of check PR title as a job.
> Good job, Yu.
>
> tison <wa...@gmail.com> 于2022年8月8日周一 22:07写道：
>
> > +1 (non-binding) to the proposal itself.
> >
> > Although, we should later move the standard to our website where the
> whole
> > project can easily contribute to and follow the general contribution
> > process - that is, send a pull request, review, and merge. I regard
> current
> > gdoc content as a temporary container for this content.
> >
> > If this proposal gets accepted, @Yu you can create an issue for the dev
> doc
> > part and ping me. I can offer my help to write so.
> >
> > Best,
> > tison.
> >
> >
> > Zike Yang <zi...@apache.org> 于2022年8月8日周一 13:35写道：
> >
> > > +1 (non-binding)
> > >
> > > Thanks
> > > Zike Yang
> > >
> > > On Mon, Aug 8, 2022 at 1:06 PM Xiangying Meng <xi...@apache.org>
> > > wrote:
> > > >
> > > > +1(non-binding)
> > > >
> > > > yours sincerely,
> > > > xiangying Meng
> > > >
> > > > On Thu, Aug 4, 2022 at 4:13 PM Yu <li...@apache.org> wrote:
> > > >
> > > > > Hi team,
> > > > >
> > > > > It has been 4 months since we discussed the [Guideline] Pulsar PR
> > > Naming
> > > > > Convention [1].
> > > > >
> > > > > Nowadays, when reading the PR list [2], you’ll find more and more
> > > people
> > > > > follow and get used to this rule.
> > > > >
> > > > > It improves collaboration efficiency, that is great!
> > > > >
> > > > > This makes us think about moving the rule forward, that is,
> > > standardizing
> > > > > PR title naming using GitHub Actions, which is a more efficient
> way.
> > > > >
> > > > > So we'd like to start a vote on PIP 198: Standardize PR Naming
> > > Convention
> > > > > using GitHub Actions [3].
> > > > >
> > > > >
> > > > > This proposal contains:
> > > > >
> > > > > - Why do this?
> > > > >
> > > > > - How do this?
> > > > >
> > > > > - Pre-discussions and other thoughts
> > > > >
> > > > > Feel free to comment, thank you!
> > > > >
> > > > > [1]
> https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
> > > > >
> > > > > [2] https://github.com/apache/pulsar/pulls
> > > > >
> > > > > [3]
> > > > >
> > > > >
> > >
> >
> https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
> > > > >
> > > > >
> > > > > Yu, Max, mangoGoForward
> > > > >
> > >
> >
>
>
> --
> BR,
> Qiang Huang
>
Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions
Posted by Qiang Huang <qi...@gmail.com>.
+1 (non-binding) I like the idea of check PR title as a job.
Good job, Yu.
tison <wa...@gmail.com> 于2022年8月8日周一 22:07写道：
> +1 (non-binding) to the proposal itself.
>
> Although, we should later move the standard to our website where the whole
> project can easily contribute to and follow the general contribution
> process - that is, send a pull request, review, and merge. I regard current
> gdoc content as a temporary container for this content.
>
> If this proposal gets accepted, @Yu you can create an issue for the dev doc
> part and ping me. I can offer my help to write so.
>
> Best,
> tison.
>
>
> Zike Yang <zi...@apache.org> 于2022年8月8日周一 13:35写道：
>
> > +1 (non-binding)
> >
> > Thanks
> > Zike Yang
> >
> > On Mon, Aug 8, 2022 at 1:06 PM Xiangying Meng <xi...@apache.org>
> > wrote:
> > >
> > > +1(non-binding)
> > >
> > > yours sincerely,
> > > xiangying Meng
> > >
> > > On Thu, Aug 4, 2022 at 4:13 PM Yu <li...@apache.org> wrote:
> > >
> > > > Hi team,
> > > >
> > > > It has been 4 months since we discussed the [Guideline] Pulsar PR
> > Naming
> > > > Convention [1].
> > > >
> > > > Nowadays, when reading the PR list [2], you’ll find more and more
> > people
> > > > follow and get used to this rule.
> > > >
> > > > It improves collaboration efficiency, that is great!
> > > >
> > > > This makes us think about moving the rule forward, that is,
> > standardizing
> > > > PR title naming using GitHub Actions, which is a more efficient way.
> > > >
> > > > So we'd like to start a vote on PIP 198: Standardize PR Naming
> > Convention
> > > > using GitHub Actions [3].
> > > >
> > > >
> > > > This proposal contains:
> > > >
> > > > - Why do this?
> > > >
> > > > - How do this?
> > > >
> > > > - Pre-discussions and other thoughts
> > > >
> > > > Feel free to comment, thank you!
> > > >
> > > > [1] https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
> > > >
> > > > [2] https://github.com/apache/pulsar/pulls
> > > >
> > > > [3]
> > > >
> > > >
> >
> https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
> > > >
> > > >
> > > > Yu, Max, mangoGoForward
> > > >
> >
>
--
BR,
Qiang Huang
Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions
Posted by tison <wa...@gmail.com>.
+1 (non-binding) to the proposal itself.
Although, we should later move the standard to our website where the whole
project can easily contribute to and follow the general contribution
process - that is, send a pull request, review, and merge. I regard current
gdoc content as a temporary container for this content.
If this proposal gets accepted, @Yu you can create an issue for the dev doc
part and ping me. I can offer my help to write so.
Best,
tison.
Zike Yang <zi...@apache.org> 于2022年8月8日周一 13:35写道：
> +1 (non-binding)
>
> Thanks
> Zike Yang
>
> On Mon, Aug 8, 2022 at 1:06 PM Xiangying Meng <xi...@apache.org>
> wrote:
> >
> > +1(non-binding)
> >
> > yours sincerely,
> > xiangying Meng
> >
> > On Thu, Aug 4, 2022 at 4:13 PM Yu <li...@apache.org> wrote:
> >
> > > Hi team,
> > >
> > > It has been 4 months since we discussed the [Guideline] Pulsar PR
> Naming
> > > Convention [1].
> > >
> > > Nowadays, when reading the PR list [2], you’ll find more and more
> people
> > > follow and get used to this rule.
> > >
> > > It improves collaboration efficiency, that is great!
> > >
> > > This makes us think about moving the rule forward, that is,
> standardizing
> > > PR title naming using GitHub Actions, which is a more efficient way.
> > >
> > > So we'd like to start a vote on PIP 198: Standardize PR Naming
> Convention
> > > using GitHub Actions [3].
> > >
> > >
> > > This proposal contains:
> > >
> > > - Why do this?
> > >
> > > - How do this?
> > >
> > > - Pre-discussions and other thoughts
> > >
> > > Feel free to comment, thank you!
> > >
> > > [1] https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
> > >
> > > [2] https://github.com/apache/pulsar/pulls
> > >
> > > [3]
> > >
> > >
> https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
> > >
> > >
> > > Yu, Max, mangoGoForward
> > >
>
Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions
Posted by Zike Yang <zi...@apache.org>.
+1 (non-binding)
Thanks
Zike Yang
On Mon, Aug 8, 2022 at 1:06 PM Xiangying Meng <xi...@apache.org> wrote:
>
> +1(non-binding)
>
> yours sincerely,
> xiangying Meng
>
> On Thu, Aug 4, 2022 at 4:13 PM Yu <li...@apache.org> wrote:
>
> > Hi team,
> >
> > It has been 4 months since we discussed the [Guideline] Pulsar PR Naming
> > Convention [1].
> >
> > Nowadays, when reading the PR list [2], you’ll find more and more people
> > follow and get used to this rule.
> >
> > It improves collaboration efficiency, that is great!
> >
> > This makes us think about moving the rule forward, that is, standardizing
> > PR title naming using GitHub Actions, which is a more efficient way.
> >
> > So we'd like to start a vote on PIP 198: Standardize PR Naming Convention
> > using GitHub Actions [3].
> >
> >
> > This proposal contains:
> >
> > - Why do this?
> >
> > - How do this?
> >
> > - Pre-discussions and other thoughts
> >
> > Feel free to comment, thank you!
> >
> > [1] https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
> >
> > [2] https://github.com/apache/pulsar/pulls
> >
> > [3]
> >
> > https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
> >
> >
> > Yu, Max, mangoGoForward
> >
Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions
Posted by Xiangying Meng <xi...@apache.org>.
+1(non-binding)
yours sincerely,
xiangying Meng
On Thu, Aug 4, 2022 at 4:13 PM Yu <li...@apache.org> wrote:
> Hi team,
>
> It has been 4 months since we discussed the [Guideline] Pulsar PR Naming
> Convention [1].
>
> Nowadays, when reading the PR list [2], you’ll find more and more people
> follow and get used to this rule.
>
> It improves collaboration efficiency, that is great!
>
> This makes us think about moving the rule forward, that is, standardizing
> PR title naming using GitHub Actions, which is a more efficient way.
>
> So we'd like to start a vote on PIP 198: Standardize PR Naming Convention
> using GitHub Actions [3].
>
>
> This proposal contains:
>
> - Why do this?
>
> - How do this?
>
> - Pre-discussions and other thoughts
>
> Feel free to comment, thank you!
>
> [1] https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
>
> [2] https://github.com/apache/pulsar/pulls
>
> [3]
>
> https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
>
>
> Yu, Max, mangoGoForward
>
Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions
Posted by PengHui Li <pe...@apache.org>.
+1
Penghui
On Fri, Aug 5, 2022 at 11:32 PM Zixuan Liu <no...@gmail.com> wrote:
> +1(non-binding)
>
> Thanks,
> Zixuan
>
> Yu <li...@apache.org> 于2022年8月4日周四 16:13写道：
>
>> Hi team,
>>
>> It has been 4 months since we discussed the [Guideline] Pulsar PR Naming
>> Convention [1].
>>
>> Nowadays, when reading the PR list [2], you’ll find more and more people
>> follow and get used to this rule.
>>
>> It improves collaboration efficiency, that is great!
>>
>> This makes us think about moving the rule forward, that is, standardizing
>> PR title naming using GitHub Actions, which is a more efficient way.
>>
>> So we'd like to start a vote on PIP 198: Standardize PR Naming Convention
>> using GitHub Actions [3].
>>
>>
>> This proposal contains:
>>
>> - Why do this?
>>
>> - How do this?
>>
>> - Pre-discussions and other thoughts
>>
>> Feel free to comment, thank you!
>>
>> [1] https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
>>
>> [2] https://github.com/apache/pulsar/pulls
>>
>> [3]
>> https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
>>
>>
>> Yu, Max, mangoGoForward
>>
>
Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions
Posted by Zixuan Liu <no...@gmail.com>.
+1(non-binding)
Thanks,
Zixuan
Yu <li...@apache.org> 于2022年8月4日周四 16:13写道：
> Hi team,
>
> It has been 4 months since we discussed the [Guideline] Pulsar PR Naming
> Convention [1].
>
> Nowadays, when reading the PR list [2], you’ll find more and more people
> follow and get used to this rule.
>
> It improves collaboration efficiency, that is great!
>
> This makes us think about moving the rule forward, that is, standardizing
> PR title naming using GitHub Actions, which is a more efficient way.
>
> So we'd like to start a vote on PIP 198: Standardize PR Naming Convention
> using GitHub Actions [3].
>
>
> This proposal contains:
>
> - Why do this?
>
> - How do this?
>
> - Pre-discussions and other thoughts
>
> Feel free to comment, thank you!
>
> [1] https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
>
> [2] https://github.com/apache/pulsar/pulls
>
> [3]
> https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
>
>
> Yu, Max, mangoGoForward
>