* [dpdk-dev] Suggestion to improve the code review @ 2020-05-27 9:28 Jerin Kollanukkaran 2020-05-27 9:59 ` Burakov, Anatoly 2020-05-27 10:08 ` Gaëtan Rivet 0 siblings, 2 replies; 9+ messages in thread From: Jerin Kollanukkaran @ 2020-05-27 9:28 UTC (permalink / raw) To: dpdk-dev, Thomas Monjalon, david.marchand, Yigit, Ferruh, Maxime Coquelin, cristian.dumitrescu, akhil.goyal, rasland, xiaolong.ye, ajit.khaparde, arybchenko, Burakov, Anatoly Cc: techboard I think, original discussion[1] on this topic got lost in GitHub vs current workflow. I would like to propose GitHub "CODEOWNERS"[2] _LIKE_ scheme for DPDK workflow. Current scheme: - When we submit a patch to ml, someone(Tree maintainer[3]) needs to manually delegate the patch to Tree maintainer in patchwork. - Tree maintainer is not responsible for the review of the patch but only responsible for merging _after_ the review. That brings the obvious question on review responsibility. Proposed scheme: - In order to improve review ownership, IMO, it is better the CI tools delegate the patch to the actual maintainer(who is responsible for specific code in MAINTAINERS file) - I believe, it provides a sense of ownership, avoids last-minute surprise on review responsibility and improve review traceability. Implementation of the proposed scheme: GitHub provides a bot for CODEOWNERS integration, Similar alternative is possible with patchwork with "auto delegation scheme" using the flowing methods: a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ b) https://patchwork.readthedocs.io/en/latest/usage/headers/ I think, option (a) would be relatively easy to change without introducing the new tools. Thoughts? [1] http://mails.dpdk.org/archives/dev/2020-May/168740.html [2] https://github.com/zephyrproject-rtos/zephyr/blob/master/CODEOWNERS [3] https://patchwork.dpdk.org/project/dpdk/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] Suggestion to improve the code review 2020-05-27 9:28 [dpdk-dev] Suggestion to improve the code review Jerin Kollanukkaran @ 2020-05-27 9:59 ` Burakov, Anatoly 2020-05-27 11:27 ` Jerin Jacob 2020-05-27 10:08 ` Gaëtan Rivet 1 sibling, 1 reply; 9+ messages in thread From: Burakov, Anatoly @ 2020-05-27 9:59 UTC (permalink / raw) To: Jerin Kollanukkaran, dpdk-dev, Thomas Monjalon, david.marchand, Yigit, Ferruh, Maxime Coquelin, cristian.dumitrescu, akhil.goyal, rasland, xiaolong.ye, ajit.khaparde, arybchenko Cc: techboard On 27-May-20 10:28 AM, Jerin Kollanukkaran wrote: > I think, original discussion[1] on this topic got lost in GitHub vs current workflow. > > > I would like to propose GitHub "CODEOWNERS"[2] _LIKE_ scheme for DPDK workflow. > > Current scheme: > - When we submit a patch to ml, someone(Tree maintainer[3]) needs to manually > delegate the patch to Tree maintainer in patchwork. > - Tree maintainer is not responsible for the review of the patch but only responsible > for merging _after_ the review. That brings the obvious question on review responsibility. > > > Proposed scheme: > - In order to improve review ownership, IMO, it is better the CI tools delegate > the patch to the actual maintainer(who is responsible for specific code in MAINTAINERS file) > - I believe, it provides a sense of ownership, avoids last-minute surprise on > review responsibility and improve review traceability. > > Implementation of the proposed scheme: > GitHub provides a bot for CODEOWNERS integration, Similar alternative is possible with > patchwork with "auto delegation scheme" using the flowing methods: > > a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ > b) https://patchwork.readthedocs.io/en/latest/usage/headers/ > > I think, option (a) would be relatively easy to change without introducing the new tools. > > Thoughts? > > [1] > http://mails.dpdk.org/archives/dev/2020-May/168740.html > [2] > https://github.com/zephyrproject-rtos/zephyr/blob/master/CODEOWNERS > [3] > https://patchwork.dpdk.org/project/dpdk/ > The "which patches should i review first" button is a huge +1000 from me, as this has been a big issue i've had with current workflow for a long time. Thomas has mentioned "Cc:" as a "fine grained" system to assign patches, but the truth is, CC is not a good way of doing it because i get CC'd in all kinds of stuff, and the important patches get lost. That said, i don't think it's that easy, because more often than not, patches touch a lot of different areas, so a one line change in meson, a test and a line in EAL gets half of DPDK maintainers CC'd into the patch. I wonder if there is a mechanism for some kind of "threshold" for assigning people to the patch - i.e. if a one-liner is half of the changes in the patch, then maintainer gets CC'd, but if a one-liner is just one of a thousand other unrelated lines, then perhaps there's no need to CC the maintainer... or something along those lines :) there's a machine learning project in here somewhere :D -- Thanks, Anatoly ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] Suggestion to improve the code review 2020-05-27 9:59 ` Burakov, Anatoly @ 2020-05-27 11:27 ` Jerin Jacob 0 siblings, 0 replies; 9+ messages in thread From: Jerin Jacob @ 2020-05-27 11:27 UTC (permalink / raw) To: Burakov, Anatoly Cc: Jerin Kollanukkaran, dpdk-dev, Thomas Monjalon, david.marchand, Yigit, Ferruh, Maxime Coquelin, cristian.dumitrescu, akhil.goyal, rasland, xiaolong.ye, ajit.khaparde, arybchenko, techboard On Wed, May 27, 2020 at 3:29 PM Burakov, Anatoly <anatoly.burakov@intel.com> wrote: > > On 27-May-20 10:28 AM, Jerin Kollanukkaran wrote: > > I think, original discussion[1] on this topic got lost in GitHub vs current workflow. > > > > > > I would like to propose GitHub "CODEOWNERS"[2] _LIKE_ scheme for DPDK workflow. > > > > Current scheme: > > - When we submit a patch to ml, someone(Tree maintainer[3]) needs to manually > > delegate the patch to Tree maintainer in patchwork. > > - Tree maintainer is not responsible for the review of the patch but only responsible > > for merging _after_ the review. That brings the obvious question on review responsibility. > > > > > > Proposed scheme: > > - In order to improve review ownership, IMO, it is better the CI tools delegate > > the patch to the actual maintainer(who is responsible for specific code in MAINTAINERS file) > > - I believe, it provides a sense of ownership, avoids last-minute surprise on > > review responsibility and improve review traceability. > > > > Implementation of the proposed scheme: > > GitHub provides a bot for CODEOWNERS integration, Similar alternative is possible with > > patchwork with "auto delegation scheme" using the flowing methods: > > > > a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ > > b) https://patchwork.readthedocs.io/en/latest/usage/headers/ > > > > I think, option (a) would be relatively easy to change without introducing the new tools. > > > > Thoughts? > > > > [1] > > http://mails.dpdk.org/archives/dev/2020-May/168740.html > > [2] > > https://github.com/zephyrproject-rtos/zephyr/blob/master/CODEOWNERS > > [3] > > https://patchwork.dpdk.org/project/dpdk/ > > > > The "which patches should i review first" button is a huge +1000 from > me, as this has been a big issue i've had with current workflow for a > long time. Thomas has mentioned "Cc:" as a "fine grained" system to > assign patches, but the truth is, CC is not a good way of doing it > because i get CC'd in all kinds of stuff, and the important patches get > lost. > > That said, i don't think it's that easy, because more often than not, > patches touch a lot of different areas, so a one line change in meson, a > test and a line in EAL gets half of DPDK maintainers CC'd into the > patch. I wonder if there is a mechanism for some kind of "threshold" for > assigning people to the patch - i.e. if a one-liner is half of the > changes in the patch, then maintainer gets CC'd, but if a one-liner is > just one of a thousand other unrelated lines, then perhaps there's no > need to CC the maintainer... or something along those lines :) there's a > machine learning project in here somewhere :D Github has a scheme on the review on Round-robin fashion if it touching in the multiple areas. it will be too much for patchwork. At least in patchwork, if you are done with the review or you can assign to another code maintainer manually. https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/managing-code-review-assignment-for-your-team > > -- > Thanks, > Anatoly ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] Suggestion to improve the code review 2020-05-27 9:28 [dpdk-dev] Suggestion to improve the code review Jerin Kollanukkaran 2020-05-27 9:59 ` Burakov, Anatoly @ 2020-05-27 10:08 ` Gaëtan Rivet 2020-06-02 12:27 ` Jerin Jacob 1 sibling, 1 reply; 9+ messages in thread From: Gaëtan Rivet @ 2020-05-27 10:08 UTC (permalink / raw) To: Jerin Kollanukkaran Cc: dpdk-dev, Thomas Monjalon, david.marchand, Yigit, Ferruh, Maxime Coquelin, cristian.dumitrescu, akhil.goyal, rasland, xiaolong.ye, ajit.khaparde, arybchenko, Burakov, Anatoly, techboard On 27/05/20 09:28 +0000, Jerin Kollanukkaran wrote: > I think, original discussion[1] on this topic got lost in GitHub vs current workflow. > > > I would like to propose GitHub "CODEOWNERS"[2] _LIKE_ scheme for DPDK workflow. > > Current scheme: > - When we submit a patch to ml, someone(Tree maintainer[3]) needs to manually > delegate the patch to Tree maintainer in patchwork. > - Tree maintainer is not responsible for the review of the patch but only responsible > for merging _after_ the review. That brings the obvious question on review responsibility. > > > Proposed scheme: > - In order to improve review ownership, IMO, it is better the CI tools delegate > the patch to the actual maintainer(who is responsible for specific code in MAINTAINERS file) > - I believe, it provides a sense of ownership, avoids last-minute surprise on > review responsibility and improve review traceability. > > Implementation of the proposed scheme: > GitHub provides a bot for CODEOWNERS integration, Similar alternative is possible with > patchwork with "auto delegation scheme" using the flowing methods: > > a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ > b) https://patchwork.readthedocs.io/en/latest/usage/headers/ > > I think, option (a) would be relatively easy to change without introducing the new tools. > > Thoughts? > > [1] > http://mails.dpdk.org/archives/dev/2020-May/168740.html > [2] > https://github.com/zephyrproject-rtos/zephyr/blob/master/CODEOWNERS > [3] > https://patchwork.dpdk.org/project/dpdk/ > Hi, +1 from me. People would be able to list current assigned tasks through pwclient. It would help reviews IMO. Not fond of having to log into github to do reviews, but I'll leave this part of the discussion to the other thread. -- Gaëtan ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] Suggestion to improve the code review 2020-05-27 10:08 ` Gaëtan Rivet @ 2020-06-02 12:27 ` Jerin Jacob 2020-06-02 14:57 ` Ferruh Yigit 0 siblings, 1 reply; 9+ messages in thread From: Jerin Jacob @ 2020-06-02 12:27 UTC (permalink / raw) To: Gaëtan Rivet Cc: Jerin Kollanukkaran, dpdk-dev, Thomas Monjalon, david.marchand, Yigit, Ferruh, Maxime Coquelin, cristian.dumitrescu, akhil.goyal, rasland, xiaolong.ye, ajit.khaparde, arybchenko, Burakov, Anatoly, techboard On Wed, May 27, 2020 at 3:38 PM Gaëtan Rivet <grive@u256.net> wrote: > > On 27/05/20 09:28 +0000, Jerin Kollanukkaran wrote: > > I think, original discussion[1] on this topic got lost in GitHub vs current workflow. > > > > > > I would like to propose GitHub "CODEOWNERS"[2] _LIKE_ scheme for DPDK workflow. > > > > Current scheme: > > - When we submit a patch to ml, someone(Tree maintainer[3]) needs to manually > > delegate the patch to Tree maintainer in patchwork. > > - Tree maintainer is not responsible for the review of the patch but only responsible > > for merging _after_ the review. That brings the obvious question on review responsibility. > > > > > > Proposed scheme: > > - In order to improve review ownership, IMO, it is better the CI tools delegate > > the patch to the actual maintainer(who is responsible for specific code in MAINTAINERS file) > > - I believe, it provides a sense of ownership, avoids last-minute surprise on > > review responsibility and improve review traceability. > > > > Implementation of the proposed scheme: > > GitHub provides a bot for CODEOWNERS integration, Similar alternative is possible with > > patchwork with "auto delegation scheme" using the flowing methods: > > > > a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ > > b) https://patchwork.readthedocs.io/en/latest/usage/headers/ > > > > I think, option (a) would be relatively easy to change without introducing the new tools. > > > > Thoughts? > > > > [1] > > http://mails.dpdk.org/archives/dev/2020-May/168740.html > > [2] > > https://github.com/zephyrproject-rtos/zephyr/blob/master/CODEOWNERS > > [3] > > https://patchwork.dpdk.org/project/dpdk/ > > > > Hi, > > +1 from me. People would be able to list current assigned tasks through > pwclient. It would help reviews IMO. So far no objection to this proposal. Any other thoughts from anyone? especially from the code maintainers. Thomas, Any input as patchwork maintainer. This would boil down to the following change in patchwork. 1) Add code maintainers are maintainers in patchwork. 2) Enable existing auto delegation[1] feature of Patchwork [1] a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ b) https://patchwork.readthedocs.io/en/latest/usage/headers/ The suggested process is: # When a patch gets submitted to ml, patchwork finds the code owner based on the MAINTAINER file using the auto delegation feature. # The code maintainer will be responsible for the "review" of that patch and patch will be delegate will code owner using auto delegation feature. # If multiple code maintainers operate on the same patch, "each code maintainer" can assign to "other code maintainer" once he is done with the review. # The existing review process will be followed as is, just that we are adding code maintainer have primary review responsibility for the patch and expressing in the patchwork. # Based on the Ack's received and/or when code owner is happy with changes, he/she can change the state to "Awaiting upstream" and assign to respective tree maintainer. # Finally, Tree maintainer will merge the patch to respective tree and make the state as "Accepted" ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] Suggestion to improve the code review 2020-06-02 12:27 ` Jerin Jacob @ 2020-06-02 14:57 ` Ferruh Yigit 2020-06-02 16:23 ` Jerin Jacob 0 siblings, 1 reply; 9+ messages in thread From: Ferruh Yigit @ 2020-06-02 14:57 UTC (permalink / raw) To: Jerin Jacob, Gaëtan Rivet Cc: Jerin Kollanukkaran, dpdk-dev, Thomas Monjalon, david.marchand, Maxime Coquelin, cristian.dumitrescu, akhil.goyal, rasland, xiaolong.ye, ajit.khaparde, arybchenko, Burakov, Anatoly, techboard On 6/2/2020 1:27 PM, Jerin Jacob wrote: > On Wed, May 27, 2020 at 3:38 PM Gaëtan Rivet <grive@u256.net> wrote: >> >> On 27/05/20 09:28 +0000, Jerin Kollanukkaran wrote: >>> I think, original discussion[1] on this topic got lost in GitHub vs current workflow. >>> >>> >>> I would like to propose GitHub "CODEOWNERS"[2] _LIKE_ scheme for DPDK workflow. >>> >>> Current scheme: >>> - When we submit a patch to ml, someone(Tree maintainer[3]) needs to manually >>> delegate the patch to Tree maintainer in patchwork. >>> - Tree maintainer is not responsible for the review of the patch but only responsible >>> for merging _after_ the review. That brings the obvious question on review responsibility. >>> >>> >>> Proposed scheme: >>> - In order to improve review ownership, IMO, it is better the CI tools delegate >>> the patch to the actual maintainer(who is responsible for specific code in MAINTAINERS file) >>> - I believe, it provides a sense of ownership, avoids last-minute surprise on >>> review responsibility and improve review traceability. >>> >>> Implementation of the proposed scheme: >>> GitHub provides a bot for CODEOWNERS integration, Similar alternative is possible with >>> patchwork with "auto delegation scheme" using the flowing methods: >>> >>> a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ >>> b) https://patchwork.readthedocs.io/en/latest/usage/headers/ >>> >>> I think, option (a) would be relatively easy to change without introducing the new tools. >>> >>> Thoughts? >>> >>> [1] >>> http://mails.dpdk.org/archives/dev/2020-May/168740.html >>> [2] >>> https://github.com/zephyrproject-rtos/zephyr/blob/master/CODEOWNERS >>> [3] >>> https://patchwork.dpdk.org/project/dpdk/ >>> >> >> Hi, >> >> +1 from me. People would be able to list current assigned tasks through >> pwclient. It would help reviews IMO. > > So far no objection to this proposal. Any other thoughts from anyone? > especially from the code maintainers. > > Thomas, Any input as patchwork maintainer. This would boil down to the > following change in patchwork. > > 1) Add code maintainers are maintainers in patchwork. > 2) Enable existing auto delegation[1] feature of Patchwork > [1] > a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ > b) https://patchwork.readthedocs.io/en/latest/usage/headers/ > > The suggested process is: > # When a patch gets submitted to ml, patchwork finds the code owner > based on the MAINTAINER file using the auto delegation feature. > # The code maintainer will be responsible for the "review" of that > patch and patch will be delegate will code owner using auto delegation > feature. > # If multiple code maintainers operate on the same patch, "each code > maintainer" can assign to "other code maintainer" once he is done with > the review. > # The existing review process will be followed as is, just that we are > adding code maintainer have primary review responsibility for the > patch and expressing in the patchwork. > # Based on the Ack's received and/or when code owner is happy with > changes, he/she can change the state to "Awaiting upstream" and > assign to respective > tree maintainer. > # Finally, Tree maintainer will merge the patch to respective tree and > make the state as "Accepted" > +1 from me, this can help maintainers to figure out patches waiting for their review. Did you have a chance to test auto delegation, will it work for us? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] Suggestion to improve the code review 2020-06-02 14:57 ` Ferruh Yigit @ 2020-06-02 16:23 ` Jerin Jacob 2020-06-03 13:09 ` Ferruh Yigit 0 siblings, 1 reply; 9+ messages in thread From: Jerin Jacob @ 2020-06-02 16:23 UTC (permalink / raw) To: Ferruh Yigit Cc: Gaëtan Rivet, Jerin Kollanukkaran, dpdk-dev, Thomas Monjalon, david.marchand, Maxime Coquelin, cristian.dumitrescu, akhil.goyal, rasland, xiaolong.ye, ajit.khaparde, arybchenko, Burakov, Anatoly, techboard On Tue, Jun 2, 2020 at 8:27 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote: > > On 6/2/2020 1:27 PM, Jerin Jacob wrote: > > On Wed, May 27, 2020 at 3:38 PM Gaëtan Rivet <grive@u256.net> wrote: > >> > >> On 27/05/20 09:28 +0000, Jerin Kollanukkaran wrote: > >>> I think, original discussion[1] on this topic got lost in GitHub vs current workflow. > >>> > >>> > >>> I would like to propose GitHub "CODEOWNERS"[2] _LIKE_ scheme for DPDK workflow. > >>> > >>> Current scheme: > >>> - When we submit a patch to ml, someone(Tree maintainer[3]) needs to manually > >>> delegate the patch to Tree maintainer in patchwork. > >>> - Tree maintainer is not responsible for the review of the patch but only responsible > >>> for merging _after_ the review. That brings the obvious question on review responsibility. > >>> > >>> > >>> Proposed scheme: > >>> - In order to improve review ownership, IMO, it is better the CI tools delegate > >>> the patch to the actual maintainer(who is responsible for specific code in MAINTAINERS file) > >>> - I believe, it provides a sense of ownership, avoids last-minute surprise on > >>> review responsibility and improve review traceability. > >>> > >>> Implementation of the proposed scheme: > >>> GitHub provides a bot for CODEOWNERS integration, Similar alternative is possible with > >>> patchwork with "auto delegation scheme" using the flowing methods: > >>> > >>> a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ > >>> b) https://patchwork.readthedocs.io/en/latest/usage/headers/ > >>> > >>> I think, option (a) would be relatively easy to change without introducing the new tools. > >>> > >>> Thoughts? > >>> > >>> [1] > >>> http://mails.dpdk.org/archives/dev/2020-May/168740.html > >>> [2] > >>> https://github.com/zephyrproject-rtos/zephyr/blob/master/CODEOWNERS > >>> [3] > >>> https://patchwork.dpdk.org/project/dpdk/ > >>> > >> > >> Hi, > >> > >> +1 from me. People would be able to list current assigned tasks through > >> pwclient. It would help reviews IMO. > > > > So far no objection to this proposal. Any other thoughts from anyone? > > especially from the code maintainers. > > > > Thomas, Any input as patchwork maintainer. This would boil down to the > > following change in patchwork. > > > > 1) Add code maintainers are maintainers in patchwork. > > 2) Enable existing auto delegation[1] feature of Patchwork > > [1] > > a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ > > b) https://patchwork.readthedocs.io/en/latest/usage/headers/ > > > > The suggested process is: > > # When a patch gets submitted to ml, patchwork finds the code owner > > based on the MAINTAINER file using the auto delegation feature. > > # The code maintainer will be responsible for the "review" of that > > patch and patch will be delegate will code owner using auto delegation > > feature. > > # If multiple code maintainers operate on the same patch, "each code > > maintainer" can assign to "other code maintainer" once he is done with > > the review. > > # The existing review process will be followed as is, just that we are > > adding code maintainer have primary review responsibility for the > > patch and expressing in the patchwork. > > # Based on the Ack's received and/or when code owner is happy with > > changes, he/she can change the state to "Awaiting upstream" and > > assign to respective > > tree maintainer. > > # Finally, Tree maintainer will merge the patch to respective tree and > > make the state as "Accepted" > > > > +1 from me, this can help maintainers to figure out patches waiting for their > review. > > Did you have a chance to test auto delegation, will it work for us? I think, it can be done in two ways a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ b) https://patchwork.readthedocs.io/en/latest/usage/headers/ Option (a) need patchwork admin access and no dependency on email client nor separate step[1]. I think, only Thomas only has access to that. I tested the option (b). It is not working, it is not straight forward as we need to specific header to email[1] Based on my debugging, Even though when I did "add-header", it is not showing up on received email. Somewhere it is getting removed[2] [1] git send-email --to dev@dpdk.org --add-header="X-Patchwork-Delegate: ferruh.yigit@intel.com" 0001-test-test-patch-for-checking-patchwork-auto-delegati.patch [2] http://patches.dpdk.org/patch/70749/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] Suggestion to improve the code review 2020-06-02 16:23 ` Jerin Jacob @ 2020-06-03 13:09 ` Ferruh Yigit 2020-06-03 13:56 ` Jerin Jacob 0 siblings, 1 reply; 9+ messages in thread From: Ferruh Yigit @ 2020-06-03 13:09 UTC (permalink / raw) To: Jerin Jacob Cc: Gaëtan Rivet, Jerin Kollanukkaran, dpdk-dev, Thomas Monjalon, david.marchand, Maxime Coquelin, cristian.dumitrescu, akhil.goyal, rasland, xiaolong.ye, ajit.khaparde, arybchenko, Burakov, Anatoly, techboard On 6/2/2020 5:23 PM, Jerin Jacob wrote: > On Tue, Jun 2, 2020 at 8:27 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote: >> >> On 6/2/2020 1:27 PM, Jerin Jacob wrote: >>> On Wed, May 27, 2020 at 3:38 PM Gaëtan Rivet <grive@u256.net> wrote: >>>> >>>> On 27/05/20 09:28 +0000, Jerin Kollanukkaran wrote: >>>>> I think, original discussion[1] on this topic got lost in GitHub vs current workflow. >>>>> >>>>> >>>>> I would like to propose GitHub "CODEOWNERS"[2] _LIKE_ scheme for DPDK workflow. >>>>> >>>>> Current scheme: >>>>> - When we submit a patch to ml, someone(Tree maintainer[3]) needs to manually >>>>> delegate the patch to Tree maintainer in patchwork. >>>>> - Tree maintainer is not responsible for the review of the patch but only responsible >>>>> for merging _after_ the review. That brings the obvious question on review responsibility. >>>>> >>>>> >>>>> Proposed scheme: >>>>> - In order to improve review ownership, IMO, it is better the CI tools delegate >>>>> the patch to the actual maintainer(who is responsible for specific code in MAINTAINERS file) >>>>> - I believe, it provides a sense of ownership, avoids last-minute surprise on >>>>> review responsibility and improve review traceability. >>>>> >>>>> Implementation of the proposed scheme: >>>>> GitHub provides a bot for CODEOWNERS integration, Similar alternative is possible with >>>>> patchwork with "auto delegation scheme" using the flowing methods: >>>>> >>>>> a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ >>>>> b) https://patchwork.readthedocs.io/en/latest/usage/headers/ >>>>> >>>>> I think, option (a) would be relatively easy to change without introducing the new tools. >>>>> >>>>> Thoughts? >>>>> >>>>> [1] >>>>> http://mails.dpdk.org/archives/dev/2020-May/168740.html >>>>> [2] >>>>> https://github.com/zephyrproject-rtos/zephyr/blob/master/CODEOWNERS >>>>> [3] >>>>> https://patchwork.dpdk.org/project/dpdk/ >>>>> >>>> >>>> Hi, >>>> >>>> +1 from me. People would be able to list current assigned tasks through >>>> pwclient. It would help reviews IMO. >>> >>> So far no objection to this proposal. Any other thoughts from anyone? >>> especially from the code maintainers. >>> >>> Thomas, Any input as patchwork maintainer. This would boil down to the >>> following change in patchwork. >>> >>> 1) Add code maintainers are maintainers in patchwork. >>> 2) Enable existing auto delegation[1] feature of Patchwork >>> [1] >>> a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ >>> b) https://patchwork.readthedocs.io/en/latest/usage/headers/ >>> >>> The suggested process is: >>> # When a patch gets submitted to ml, patchwork finds the code owner >>> based on the MAINTAINER file using the auto delegation feature. >>> # The code maintainer will be responsible for the "review" of that >>> patch and patch will be delegate will code owner using auto delegation >>> feature. >>> # If multiple code maintainers operate on the same patch, "each code >>> maintainer" can assign to "other code maintainer" once he is done with >>> the review. >>> # The existing review process will be followed as is, just that we are >>> adding code maintainer have primary review responsibility for the >>> patch and expressing in the patchwork. >>> # Based on the Ack's received and/or when code owner is happy with >>> changes, he/she can change the state to "Awaiting upstream" and >>> assign to respective >>> tree maintainer. >>> # Finally, Tree maintainer will merge the patch to respective tree and >>> make the state as "Accepted" >>> >> >> +1 from me, this can help maintainers to figure out patches waiting for their >> review. >> >> Did you have a chance to test auto delegation, will it work for us? > > I think, it can be done in two ways > > a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ > b) https://patchwork.readthedocs.io/en/latest/usage/headers/ > > Option (a) need patchwork admin access and no dependency on email > client nor separate step[1]. I think, only Thomas only has access to > that. > I tested the option (b). It is not working, it is not straight forward > as we need to specific header to email[1] > Based on my debugging, Even though when I did "add-header", it is not > showing up on received email. Somewhere it is getting removed[2] > > [1] > git send-email --to dev@dpdk.org --add-header="X-Patchwork-Delegate: > ferruh.yigit@intel.com" > 0001-test-test-patch-for-checking-patchwork-auto-delegati.patch > [2] > http://patches.dpdk.org/patch/70749/ > I did able add the header to the email, it worked if you gave the '--add-header' to "git format-patch" and send that patch, instead of using "git send-email" directly: http://inbox.dpdk.org/dev/20200603130005.3709131-1-ferruh.yigit@intel.com/raw X-Patchwork-Delegate: ferruh.yigit@intel.com But it didn't show up in the patchwork, not sure why. Also this way is not a good solution, instead of the sender of the patch delegating, this should be automated in the server side. I think option a) above is the way to go. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] Suggestion to improve the code review 2020-06-03 13:09 ` Ferruh Yigit @ 2020-06-03 13:56 ` Jerin Jacob 0 siblings, 0 replies; 9+ messages in thread From: Jerin Jacob @ 2020-06-03 13:56 UTC (permalink / raw) To: Ferruh Yigit Cc: Gaëtan Rivet, Jerin Kollanukkaran, dpdk-dev, Thomas Monjalon, david.marchand, Maxime Coquelin, cristian.dumitrescu, akhil.goyal, rasland, xiaolong.ye, ajit.khaparde, arybchenko, Burakov, Anatoly, techboard On Wed, Jun 3, 2020 at 6:39 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote: > > On 6/2/2020 5:23 PM, Jerin Jacob wrote: > > On Tue, Jun 2, 2020 at 8:27 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote: > >> > >> On 6/2/2020 1:27 PM, Jerin Jacob wrote: > >>> On Wed, May 27, 2020 at 3:38 PM Gaëtan Rivet <grive@u256.net> wrote: > >>>> > >>>> On 27/05/20 09:28 +0000, Jerin Kollanukkaran wrote: > >>>>> I think, original discussion[1] on this topic got lost in GitHub vs current workflow. > >>>>> > >>>>> > >>>>> I would like to propose GitHub "CODEOWNERS"[2] _LIKE_ scheme for DPDK workflow. > >>>>> > >>>>> Current scheme: > >>>>> - When we submit a patch to ml, someone(Tree maintainer[3]) needs to manually > >>>>> delegate the patch to Tree maintainer in patchwork. > >>>>> - Tree maintainer is not responsible for the review of the patch but only responsible > >>>>> for merging _after_ the review. That brings the obvious question on review responsibility. > >>>>> > >>>>> > >>>>> Proposed scheme: > >>>>> - In order to improve review ownership, IMO, it is better the CI tools delegate > >>>>> the patch to the actual maintainer(who is responsible for specific code in MAINTAINERS file) > >>>>> - I believe, it provides a sense of ownership, avoids last-minute surprise on > >>>>> review responsibility and improve review traceability. > >>>>> > >>>>> Implementation of the proposed scheme: > >>>>> GitHub provides a bot for CODEOWNERS integration, Similar alternative is possible with > >>>>> patchwork with "auto delegation scheme" using the flowing methods: > >>>>> > >>>>> a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ > >>>>> b) https://patchwork.readthedocs.io/en/latest/usage/headers/ > >>>>> > >>>>> I think, option (a) would be relatively easy to change without introducing the new tools. > >>>>> > >>>>> Thoughts? > >>>>> > >>>>> [1] > >>>>> http://mails.dpdk.org/archives/dev/2020-May/168740.html > >>>>> [2] > >>>>> https://github.com/zephyrproject-rtos/zephyr/blob/master/CODEOWNERS > >>>>> [3] > >>>>> https://patchwork.dpdk.org/project/dpdk/ > >>>>> > >>>> > >>>> Hi, > >>>> > >>>> +1 from me. People would be able to list current assigned tasks through > >>>> pwclient. It would help reviews IMO. > >>> > >>> So far no objection to this proposal. Any other thoughts from anyone? > >>> especially from the code maintainers. > >>> > >>> Thomas, Any input as patchwork maintainer. This would boil down to the > >>> following change in patchwork. > >>> > >>> 1) Add code maintainers are maintainers in patchwork. > >>> 2) Enable existing auto delegation[1] feature of Patchwork > >>> [1] > >>> a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ > >>> b) https://patchwork.readthedocs.io/en/latest/usage/headers/ > >>> > >>> The suggested process is: > >>> # When a patch gets submitted to ml, patchwork finds the code owner > >>> based on the MAINTAINER file using the auto delegation feature. > >>> # The code maintainer will be responsible for the "review" of that > >>> patch and patch will be delegate will code owner using auto delegation > >>> feature. > >>> # If multiple code maintainers operate on the same patch, "each code > >>> maintainer" can assign to "other code maintainer" once he is done with > >>> the review. > >>> # The existing review process will be followed as is, just that we are > >>> adding code maintainer have primary review responsibility for the > >>> patch and expressing in the patchwork. > >>> # Based on the Ack's received and/or when code owner is happy with > >>> changes, he/she can change the state to "Awaiting upstream" and > >>> assign to respective > >>> tree maintainer. > >>> # Finally, Tree maintainer will merge the patch to respective tree and > >>> make the state as "Accepted" > >>> > >> > >> +1 from me, this can help maintainers to figure out patches waiting for their > >> review. > >> > >> Did you have a chance to test auto delegation, will it work for us? > > > > I think, it can be done in two ways > > > > a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ > > b) https://patchwork.readthedocs.io/en/latest/usage/headers/ > > > > Option (a) need patchwork admin access and no dependency on email > > client nor separate step[1]. I think, only Thomas only has access to > > that. > > I tested the option (b). It is not working, it is not straight forward > > as we need to specific header to email[1] > > Based on my debugging, Even though when I did "add-header", it is not > > showing up on received email. Somewhere it is getting removed[2] > > > > [1] > > git send-email --to dev@dpdk.org --add-header="X-Patchwork-Delegate: > > ferruh.yigit@intel.com" > > 0001-test-test-patch-for-checking-patchwork-auto-delegati.patch > > [2] > > http://patches.dpdk.org/patch/70749/ > > > > I did able add the header to the email, it worked if you gave the '--add-header' > to "git format-patch" and send that patch, instead of using "git send-email" > directly: > http://inbox.dpdk.org/dev/20200603130005.3709131-1-ferruh.yigit@intel.com/raw > X-Patchwork-Delegate: ferruh.yigit@intel.com > > But it didn't show up in the patchwork, not sure why. > > Also this way is not a good solution, instead of the sender of the patch > delegating, this should be automated in the server side. I think option a) above > is the way to go. Yes. option a) is always better. Patchwork admin can only test option (a). Looking forward for Thomas's cycles to check if he agee with this process. Another option could be to have wrapper script for git format-patch to to add -add-header using ./devtools/get-maintainer.sh script so that it is completely automated if option (a) not viable. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-06-03 13:56 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-27 9:28 [dpdk-dev] Suggestion to improve the code review Jerin Kollanukkaran 2020-05-27 9:59 ` Burakov, Anatoly 2020-05-27 11:27 ` Jerin Jacob 2020-05-27 10:08 ` Gaëtan Rivet 2020-06-02 12:27 ` Jerin Jacob 2020-06-02 14:57 ` Ferruh Yigit 2020-06-02 16:23 ` Jerin Jacob 2020-06-03 13:09 ` Ferruh Yigit 2020-06-03 13:56 ` Jerin Jacob
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).