Re: Using gerrit or github for review?
Hi Pratyush, On Fri, 24 Jul 2020 at 07:30, Pratyush Yadav wrote: > > Hi, > > I'm a bit late to this discussion, but I'll drop my $0.02 anyway. > > On 13/07/20 02:06PM, Simon Glass wrote: > > Hi Heinrich, > > > > On Mon, 13 Jul 2020 at 13:36, Heinrich Schuchardt > > wrote: > > > > > > On 13.07.20 20:25, Simon Glass wrote: > > > > Hi, > > > > > > > > At present U-Boot uses the mailing list for patch review. What do > > > > > > Currently we are using Patchwork to keep track of the review process: > > > > > > https://patchwork.ozlabs.org/project/uboot/list/ > > > > > > > people think about trying out geritt or github for this? I'd be > > > > willing to do a trial with the -dm mailing list. > > > > > > > > My idea is that patman would email out the patches and also upload > > > > them to one of these systems. With geritt, emails are sent every time > > > > there is a review, but for github I'm not sure. > > > > > > Do we need an new tool? Managing reviews it supported by Gitlab. > > > > > > There is no need for patman in a process with any of the mentioned > > > tools. Gitlab, Gerrit, and Github send out mails to reviewers. > > > > > > The work flow with Gitlab and Gerrit that I have seen relied on a role > > > concept where only specific users of the system are reviewers. - Our > > > current process allows anybody to review. This is what I would like to > > > keep. > > > > > > Simon, could you, please, explain why you want to change the current > > > process. > > > > I have used various tools and I'm wondering whether having another > > option might have some benefits in terms of productivity, automation > > and accessibility. Just as one example, if people pushed patches to > > github / gitlab then we could 1) check out the branch and try it, 2) > > have test automation attached, 3) use a UI for review. > > > > So that is the purpose of my email. > > You might want to look into GitGitGadget (GGG in short) [0][1]. GGG lets > you open GitHub Pull Requests and it will convert them to patch form and > send them to the Git mailing list. It works pretty well for the most > part (though I haven't ever used personally. Just observed other people > using it a lot). It automatically adds version number to patches, and > even CCs the subsystem maintainers automatically (as of now there are > only two, but it shouldn't be difficult to extend it to use > get_maintainer.pl). It also watches for replies on the email thread and > shows them in comments to the Pull Request. It also runs CI build and > tests for each PR. > > One major limitation of the tool is that while you can read replies to > the email thread, you can't send replies. You'd still need a plain text > email client to do that. I attempted to solve this problem once but I > didn't make much progress partly due to lack of time and partly due lack > of TypeScript and Azure experience. But I think it can be done. > > I think it can help bridge the gap between the mailing list workflow and > the GitHub workflow. If anyone is interested, they can try porting it to > work with the U-Boot mailing list. Thanks for the info. Certainly it would be good to integrate email and a web-based review interface. Sending out emails is easy but parsing them is less so (I added something very basic in patman for this). Given that we currently use gitlab I think it would be good to do an email integration with that. But it doesn't seem to have anything connected to code review at present [2] and the same with gerrit [3] which has lacked this features for years and years, so I'm guessing it must be hard. For gitlab we might be able to write a separate tool that uses the API to email out reviews and attach incoming reviews to the gitlab code. But another option is to allow code review in gitlab on a repo and see how things go. Regards, Simon [2] https://docs.gitlab.com/ee/administration/incoming_email.html [3] https://gerrit-review.googlesource.com/Documentation/intro-user.html > > [0] https://github.com/gitgitgadget/gitgitgadget > [1] https://github.com/gitgitgadget/git > > -- > Regards, > Pratyush Yadav > Texas Instruments India
Re: Using gerrit or github for review?
Hi, I'm a bit late to this discussion, but I'll drop my $0.02 anyway. On 13/07/20 02:06PM, Simon Glass wrote: > Hi Heinrich, > > On Mon, 13 Jul 2020 at 13:36, Heinrich Schuchardt wrote: > > > > On 13.07.20 20:25, Simon Glass wrote: > > > Hi, > > > > > > At present U-Boot uses the mailing list for patch review. What do > > > > Currently we are using Patchwork to keep track of the review process: > > > > https://patchwork.ozlabs.org/project/uboot/list/ > > > > > people think about trying out geritt or github for this? I'd be > > > willing to do a trial with the -dm mailing list. > > > > > > My idea is that patman would email out the patches and also upload > > > them to one of these systems. With geritt, emails are sent every time > > > there is a review, but for github I'm not sure. > > > > Do we need an new tool? Managing reviews it supported by Gitlab. > > > > There is no need for patman in a process with any of the mentioned > > tools. Gitlab, Gerrit, and Github send out mails to reviewers. > > > > The work flow with Gitlab and Gerrit that I have seen relied on a role > > concept where only specific users of the system are reviewers. - Our > > current process allows anybody to review. This is what I would like to keep. > > > > Simon, could you, please, explain why you want to change the current > > process. > > I have used various tools and I'm wondering whether having another > option might have some benefits in terms of productivity, automation > and accessibility. Just as one example, if people pushed patches to > github / gitlab then we could 1) check out the branch and try it, 2) > have test automation attached, 3) use a UI for review. > > So that is the purpose of my email. You might want to look into GitGitGadget (GGG in short) [0][1]. GGG lets you open GitHub Pull Requests and it will convert them to patch form and send them to the Git mailing list. It works pretty well for the most part (though I haven't ever used personally. Just observed other people using it a lot). It automatically adds version number to patches, and even CCs the subsystem maintainers automatically (as of now there are only two, but it shouldn't be difficult to extend it to use get_maintainer.pl). It also watches for replies on the email thread and shows them in comments to the Pull Request. It also runs CI build and tests for each PR. One major limitation of the tool is that while you can read replies to the email thread, you can't send replies. You'd still need a plain text email client to do that. I attempted to solve this problem once but I didn't make much progress partly due to lack of time and partly due lack of TypeScript and Azure experience. But I think it can be done. I think it can help bridge the gap between the mailing list workflow and the GitHub workflow. If anyone is interested, they can try porting it to work with the U-Boot mailing list. [0] https://github.com/gitgitgadget/gitgitgadget [1] https://github.com/gitgitgadget/git -- Regards, Pratyush Yadav Texas Instruments India
Re: Using gerrit or github for review?
Hi all On Wed, Jul 15, 2020 at 3:08 AM Simon Glass wrote: > > Hi, > > On Tue, 14 Jul 2020 at 14:06, Karsten Merker wrote: > > > > On Mon, Jul 13, 2020 at 06:05:42PM -0400, Corey Clayton wrote: > > > On Mon, Jul 13, 2020 at 12:25:42PM -0600, Simon Glass wrote: > > > > > > > At present U-Boot uses the mailing list for patch review. What do > > > > people think about trying out geritt or github for this? I'd be > > > > willing to do a trial with the -dm mailing list. > > > > > > This is both my first message to the mailing list and my first > > > email sent using mutt. I'm hoping to eventually participate > > > with patches and reviews but the mailing-list-driven > > > developement model has been a barrier for myself an probably > > > many others. I'm slowly trying to climb over it now but some > > > will never find the time. Perhaps a good question is: How long > > > does it take to learn the mailing-list workflow vs the github > > > workflow? > > > > > > If u-boot was using github, I would have contributed long ago > > > and I suspect there are others in the same bucket. Thats my > > > perspective at least :) > > > > Hello, > > > > to provide a different perspective: if U-Boot would have done > > everything inside github instead of using its traditional > > mailinglist-based workflow, I would never have contributed to > > U-Boot, and moving everything from the mailinglist to github > > would make any future contributions infeasible for me. > > > > The github workflow makes it impossible to open an issue or to > > comment on an existing issue or to provide feedback about a patch > > without being a github customer, and becoming a github customer > > is not an option for me (and quite a number of other open-source > > developers) as the github TOS contain clauses that I (and other > > people) consider completely unacceptable. > > > > Besides the aforementioned points I am generally concerned about > > the closed nature of the github issue- and pull-request system. > > While it is of course easily possible to move a git repo from > > github to somewhere else, it is as far as I know (please correct > > me if I should me misinformed here) not possible to export the > > comments and discussions in issues and pull requests in any > > meaningful way to some other hosting platform, which creates a > > strong vendor-lock-in once a project starts using the github > > issue and pull-request facilities. With the traditional > > mailinglist-based workflow on the other hand, moving everything > > to another hosting platform is trivial, so vendor-lock-in > > is not a problem there. > > > > Another problem that I see in the github workflow is that it > > requires being online all the time while the mailinglist-based > > workflow makes it easy to read and comment on patches while being > > offline. I am sure that many people will now think "everybody is > > online all day nowadays", but that's not true everywhere. I for > > example travel a lot by train and use the time on the train for > > catching up with current developments and for reviewing things. > > Where I live, for most practical purposes being on the train > > effectively means being offline as far as modern web applications > > are concerned. Availability of mobile internet access is spotty > > at best, and if one has internet connectivity inside the train at > > all, it is often so slow that using it for interactive work on a > > web interface is not feasible. Receiving, writing and sending > > emails on the other hand works without problems even with spotty > > and slow internet connectivity. > > Just to clarify, my question was whether we should add a new workflow. > I don't think there is any interest in removing the mailing-list flow. > > Re your comments about the TOS - what specifically causes problems? Re > exporting comment I have been wondering that...is there no API for it? > Finally, do your comments apply to gerrit and gitlab as well? We are using gerrit and works for us in multi-project repo very well as in single project. We have verification build connected to jenkins. I prefer gerrit over github and gitlab becuse I still don't found a way to review commit message itseld on the other system. Gerrit store in git review and is moving forward even on comment using email. For the last I tried some version ago. Michael > > Regards, > Simon -- Michael Nazzareno Trimarchi Amarula Solutions BV COO Co-Founder Cruquiuskade 47 Amsterdam 1018 AM NL T. +31(0)851119172 M. +39(0)3479132170 [`as] https://www.amarulasolutions.com
Re: Using gerrit or github for review?
Hi, On Tue, 14 Jul 2020 at 14:06, Karsten Merker wrote: > > On Mon, Jul 13, 2020 at 06:05:42PM -0400, Corey Clayton wrote: > > On Mon, Jul 13, 2020 at 12:25:42PM -0600, Simon Glass wrote: > > > > > At present U-Boot uses the mailing list for patch review. What do > > > people think about trying out geritt or github for this? I'd be > > > willing to do a trial with the -dm mailing list. > > > > This is both my first message to the mailing list and my first > > email sent using mutt. I'm hoping to eventually participate > > with patches and reviews but the mailing-list-driven > > developement model has been a barrier for myself an probably > > many others. I'm slowly trying to climb over it now but some > > will never find the time. Perhaps a good question is: How long > > does it take to learn the mailing-list workflow vs the github > > workflow? > > > > If u-boot was using github, I would have contributed long ago > > and I suspect there are others in the same bucket. Thats my > > perspective at least :) > > Hello, > > to provide a different perspective: if U-Boot would have done > everything inside github instead of using its traditional > mailinglist-based workflow, I would never have contributed to > U-Boot, and moving everything from the mailinglist to github > would make any future contributions infeasible for me. > > The github workflow makes it impossible to open an issue or to > comment on an existing issue or to provide feedback about a patch > without being a github customer, and becoming a github customer > is not an option for me (and quite a number of other open-source > developers) as the github TOS contain clauses that I (and other > people) consider completely unacceptable. > > Besides the aforementioned points I am generally concerned about > the closed nature of the github issue- and pull-request system. > While it is of course easily possible to move a git repo from > github to somewhere else, it is as far as I know (please correct > me if I should me misinformed here) not possible to export the > comments and discussions in issues and pull requests in any > meaningful way to some other hosting platform, which creates a > strong vendor-lock-in once a project starts using the github > issue and pull-request facilities. With the traditional > mailinglist-based workflow on the other hand, moving everything > to another hosting platform is trivial, so vendor-lock-in > is not a problem there. > > Another problem that I see in the github workflow is that it > requires being online all the time while the mailinglist-based > workflow makes it easy to read and comment on patches while being > offline. I am sure that many people will now think "everybody is > online all day nowadays", but that's not true everywhere. I for > example travel a lot by train and use the time on the train for > catching up with current developments and for reviewing things. > Where I live, for most practical purposes being on the train > effectively means being offline as far as modern web applications > are concerned. Availability of mobile internet access is spotty > at best, and if one has internet connectivity inside the train at > all, it is often so slow that using it for interactive work on a > web interface is not feasible. Receiving, writing and sending > emails on the other hand works without problems even with spotty > and slow internet connectivity. Just to clarify, my question was whether we should add a new workflow. I don't think there is any interest in removing the mailing-list flow. Re your comments about the TOS - what specifically causes problems? Re exporting comment I have been wondering that...is there no API for it? Finally, do your comments apply to gerrit and gitlab as well? Regards, Simon
Re: Using gerrit or github for review?
On Mon, Jul 13, 2020 at 06:05:42PM -0400, Corey Clayton wrote: > On Mon, Jul 13, 2020 at 12:25:42PM -0600, Simon Glass wrote: > > > At present U-Boot uses the mailing list for patch review. What do > > people think about trying out geritt or github for this? I'd be > > willing to do a trial with the -dm mailing list. > > This is both my first message to the mailing list and my first > email sent using mutt. I'm hoping to eventually participate > with patches and reviews but the mailing-list-driven > developement model has been a barrier for myself an probably > many others. I'm slowly trying to climb over it now but some > will never find the time. Perhaps a good question is: How long > does it take to learn the mailing-list workflow vs the github > workflow? > > If u-boot was using github, I would have contributed long ago > and I suspect there are others in the same bucket. Thats my > perspective at least :) Hello, to provide a different perspective: if U-Boot would have done everything inside github instead of using its traditional mailinglist-based workflow, I would never have contributed to U-Boot, and moving everything from the mailinglist to github would make any future contributions infeasible for me. The github workflow makes it impossible to open an issue or to comment on an existing issue or to provide feedback about a patch without being a github customer, and becoming a github customer is not an option for me (and quite a number of other open-source developers) as the github TOS contain clauses that I (and other people) consider completely unacceptable. Besides the aforementioned points I am generally concerned about the closed nature of the github issue- and pull-request system. While it is of course easily possible to move a git repo from github to somewhere else, it is as far as I know (please correct me if I should me misinformed here) not possible to export the comments and discussions in issues and pull requests in any meaningful way to some other hosting platform, which creates a strong vendor-lock-in once a project starts using the github issue and pull-request facilities. With the traditional mailinglist-based workflow on the other hand, moving everything to another hosting platform is trivial, so vendor-lock-in is not a problem there. Another problem that I see in the github workflow is that it requires being online all the time while the mailinglist-based workflow makes it easy to read and comment on patches while being offline. I am sure that many people will now think "everybody is online all day nowadays", but that's not true everywhere. I for example travel a lot by train and use the time on the train for catching up with current developments and for reviewing things. Where I live, for most practical purposes being on the train effectively means being offline as far as modern web applications are concerned. Availability of mobile internet access is spotty at best, and if one has internet connectivity inside the train at all, it is often so slow that using it for interactive work on a web interface is not feasible. Receiving, writing and sending emails on the other hand works without problems even with spotty and slow internet connectivity. Regards, Karsten -- Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Re: Using gerrit or github for review?
On Tue, Jul 14, 2020 at 08:09:23AM +0200, Michal Simek wrote: > > > On 13. 07. 20 22:36, Tom Rini wrote: > > On Mon, Jul 13, 2020 at 12:25:42PM -0600, Simon Glass wrote: > > > >> Hi, > >> > >> At present U-Boot uses the mailing list for patch review. What do > >> people think about trying out geritt or github for this? I'd be > >> willing to do a trial with the -dm mailing list. > >> > >> My idea is that patman would email out the patches and also upload > >> them to one of these systems. With geritt, emails are sent every time > >> there is a review, but for github I'm not sure. > > > > As you said, you also intended to include gitlab in the list. > > > > So, things that I think could be better, or more widely known, would be > > how to trigger Azure CI runs (as there's good resources available for > > free) and GitLab for non-custodians. By which I mean, anyone can get a > > CI run on Azure today via a GitHub PR. Making that known more widely > > would be good. > > > > For patch review, are there any of the Linux kernel bots that are well > > enough documented for someone else to pick up and use? I feel like our > > biggest problems are: > > - Lack of reviewers in general for various areas. > > - Lack of feedback to users (developers) before being picked up for > > general changes. > > > > For the second problem, I feel like some of the Linux bots would be a > > little helpful, but probably require some tweaking (figure out when / > > how to fire off more limited CI, or just do a daily CI run vs every > > patch, given the size of our CI build). > > > > Don't have details but patchwork should support (somehow) to run some > checks. > Here you can see it working. > http://patchwork.ozlabs.org/project/devicetree-bindings/patch/1594676120-5862-7-git-send-email-prabhakar.mahadev-lad...@bp.renesas.com/ > or > http://patchwork.ozlabs.org/project/devicetree-bindings/patch/20200713132927.24925-2-abai...@baylibre.com/ > > It means when the patch reach patchwork checks can run. Would be > wonderful to get PASS/FAIL with link via email from CI loop. > > I don't have experience with gerrit but definitely don't like using > github for contribution and prefer to use review based on emails. Oh wow, that is useful. Rob, can you share what you're doing for that? Thanks! -- Tom signature.asc Description: PGP signature
Re: Using gerrit or github for review?
Hello Heinrich, Am 14.07.2020 um 08:34 schrieb Heinrich Schuchardt: On 7/14/20 8:22 AM, Heiko Schocher wrote: Hi Michal, Am 14.07.2020 um 08:09 schrieb Michal Simek: On 13. 07. 20 22:36, Tom Rini wrote: On Mon, Jul 13, 2020 at 12:25:42PM -0600, Simon Glass wrote: Hi, At present U-Boot uses the mailing list for patch review. What do people think about trying out geritt or github for this? I'd be willing to do a trial with the -dm mailing list. My idea is that patman would email out the patches and also upload them to one of these systems. With geritt, emails are sent every time there is a review, but for github I'm not sure. As you said, you also intended to include gitlab in the list. So, things that I think could be better, or more widely known, would be how to trigger Azure CI runs (as there's good resources available for free) and GitLab for non-custodians. By which I mean, anyone can get a CI run on Azure today via a GitHub PR. Making that known more widely would be good. For patch review, are there any of the Linux kernel bots that are well enough documented for someone else to pick up and use? I feel like our biggest problems are: - Lack of reviewers in general for various areas. - Lack of feedback to users (developers) before being picked up for general changes. For the second problem, I feel like some of the Linux bots would be a little helpful, but probably require some tweaking (figure out when / how to fire off more limited CI, or just do a daily CI run vs every patch, given the size of our CI build). Don't have details but patchwork should support (somehow) to run some checks. Here you can see it working. http://patchwork.ozlabs.org/project/devicetree-bindings/patch/1594676120-5862-7-git-send-email-prabhakar.mahadev-lad...@bp.renesas.com/ or http://patchwork.ozlabs.org/project/devicetree-bindings/patch/20200713132927.24925-2-abai...@baylibre.com/ It means when the patch reach patchwork checks can run. Would be wonderful to get PASS/FAIL with link via email from CI loop. The software you need for it is https://github.com/ruscur/snowpatch and Jenkins. Ah, thanks for the tip! bye, Heiko Best regards Heinrich That looks interesting, indeed! I don't have experience with gerrit but definitely don't like using github for contribution and prefer to use review based on emails. me too. bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: Using gerrit or github for review?
On 7/14/20 8:22 AM, Heiko Schocher wrote: > Hi Michal, > > Am 14.07.2020 um 08:09 schrieb Michal Simek: >> >> >> On 13. 07. 20 22:36, Tom Rini wrote: >>> On Mon, Jul 13, 2020 at 12:25:42PM -0600, Simon Glass wrote: >>> Hi, At present U-Boot uses the mailing list for patch review. What do people think about trying out geritt or github for this? I'd be willing to do a trial with the -dm mailing list. My idea is that patman would email out the patches and also upload them to one of these systems. With geritt, emails are sent every time there is a review, but for github I'm not sure. >>> >>> As you said, you also intended to include gitlab in the list. >>> >>> So, things that I think could be better, or more widely known, would be >>> how to trigger Azure CI runs (as there's good resources available for >>> free) and GitLab for non-custodians. By which I mean, anyone can get a >>> CI run on Azure today via a GitHub PR. Making that known more widely >>> would be good. >>> >>> For patch review, are there any of the Linux kernel bots that are well >>> enough documented for someone else to pick up and use? I feel like our >>> biggest problems are: >>> - Lack of reviewers in general for various areas. >>> - Lack of feedback to users (developers) before being picked up for >>> general changes. >>> >>> For the second problem, I feel like some of the Linux bots would be a >>> little helpful, but probably require some tweaking (figure out when / >>> how to fire off more limited CI, or just do a daily CI run vs every >>> patch, given the size of our CI build). >>> >> >> Don't have details but patchwork should support (somehow) to run some >> checks. >> Here you can see it working. >> http://patchwork.ozlabs.org/project/devicetree-bindings/patch/1594676120-5862-7-git-send-email-prabhakar.mahadev-lad...@bp.renesas.com/ >> >> or >> http://patchwork.ozlabs.org/project/devicetree-bindings/patch/20200713132927.24925-2-abai...@baylibre.com/ >> >> >> It means when the patch reach patchwork checks can run. Would be >> wonderful to get PASS/FAIL with link via email from CI loop. The software you need for it is https://github.com/ruscur/snowpatch and Jenkins. Best regards Heinrich > > That looks interesting, indeed! > >> I don't have experience with gerrit but definitely don't like using >> github for contribution and prefer to use review based on emails. > > me too. > > bye, > Heiko
Re: Using gerrit or github for review?
Hi Michal, Am 14.07.2020 um 08:22 schrieb Heiko Schocher: Hi Michal, Am 14.07.2020 um 08:09 schrieb Michal Simek: On 13. 07. 20 22:36, Tom Rini wrote: On Mon, Jul 13, 2020 at 12:25:42PM -0600, Simon Glass wrote: Hi, At present U-Boot uses the mailing list for patch review. What do people think about trying out geritt or github for this? I'd be willing to do a trial with the -dm mailing list. My idea is that patman would email out the patches and also upload them to one of these systems. With geritt, emails are sent every time there is a review, but for github I'm not sure. As you said, you also intended to include gitlab in the list. So, things that I think could be better, or more widely known, would be how to trigger Azure CI runs (as there's good resources available for free) and GitLab for non-custodians. By which I mean, anyone can get a CI run on Azure today via a GitHub PR. Making that known more widely would be good. For patch review, are there any of the Linux kernel bots that are well enough documented for someone else to pick up and use? I feel like our biggest problems are: - Lack of reviewers in general for various areas. - Lack of feedback to users (developers) before being picked up for general changes. For the second problem, I feel like some of the Linux bots would be a little helpful, but probably require some tweaking (figure out when / how to fire off more limited CI, or just do a daily CI run vs every patch, given the size of our CI build). Don't have details but patchwork should support (somehow) to run some checks. Here you can see it working. http://patchwork.ozlabs.org/project/devicetree-bindings/patch/1594676120-5862-7-git-send-email-prabhakar.mahadev-lad...@bp.renesas.com/ or http://patchwork.ozlabs.org/project/devicetree-bindings/patch/20200713132927.24925-2-abai...@baylibre.com/ It means when the patch reach patchwork checks can run. Would be wonderful to get PASS/FAIL with link via email from CI loop. That looks interesting, indeed! A fast google search: https://patchwork-freedesktop.readthedocs.io/en/latest/testing.html Ok, I think in tbot (sorry) ... make a small script which periodically polls the patchwork api for a new event: https://patchwork-freedesktop.readthedocs.io/en/latest/testing.html#polling-for-events and than start tbot which do all the stuff (download patches, check them apply, build... call test.py) and write a tbot generator which post testresult back to patchwork... sounds easy and interesting... Damn, I have no time currently to prepare such a demo ... (I think, it can run in 1-2 work days... so if people think this is interesting may I find some time on weekend...) bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: Using gerrit or github for review?
Hi Michal, Am 14.07.2020 um 08:09 schrieb Michal Simek: On 13. 07. 20 22:36, Tom Rini wrote: On Mon, Jul 13, 2020 at 12:25:42PM -0600, Simon Glass wrote: Hi, At present U-Boot uses the mailing list for patch review. What do people think about trying out geritt or github for this? I'd be willing to do a trial with the -dm mailing list. My idea is that patman would email out the patches and also upload them to one of these systems. With geritt, emails are sent every time there is a review, but for github I'm not sure. As you said, you also intended to include gitlab in the list. So, things that I think could be better, or more widely known, would be how to trigger Azure CI runs (as there's good resources available for free) and GitLab for non-custodians. By which I mean, anyone can get a CI run on Azure today via a GitHub PR. Making that known more widely would be good. For patch review, are there any of the Linux kernel bots that are well enough documented for someone else to pick up and use? I feel like our biggest problems are: - Lack of reviewers in general for various areas. - Lack of feedback to users (developers) before being picked up for general changes. For the second problem, I feel like some of the Linux bots would be a little helpful, but probably require some tweaking (figure out when / how to fire off more limited CI, or just do a daily CI run vs every patch, given the size of our CI build). Don't have details but patchwork should support (somehow) to run some checks. Here you can see it working. http://patchwork.ozlabs.org/project/devicetree-bindings/patch/1594676120-5862-7-git-send-email-prabhakar.mahadev-lad...@bp.renesas.com/ or http://patchwork.ozlabs.org/project/devicetree-bindings/patch/20200713132927.24925-2-abai...@baylibre.com/ It means when the patch reach patchwork checks can run. Would be wonderful to get PASS/FAIL with link via email from CI loop. That looks interesting, indeed! I don't have experience with gerrit but definitely don't like using github for contribution and prefer to use review based on emails. me too. bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: Using gerrit or github for review?
On 13. 07. 20 22:36, Tom Rini wrote: > On Mon, Jul 13, 2020 at 12:25:42PM -0600, Simon Glass wrote: > >> Hi, >> >> At present U-Boot uses the mailing list for patch review. What do >> people think about trying out geritt or github for this? I'd be >> willing to do a trial with the -dm mailing list. >> >> My idea is that patman would email out the patches and also upload >> them to one of these systems. With geritt, emails are sent every time >> there is a review, but for github I'm not sure. > > As you said, you also intended to include gitlab in the list. > > So, things that I think could be better, or more widely known, would be > how to trigger Azure CI runs (as there's good resources available for > free) and GitLab for non-custodians. By which I mean, anyone can get a > CI run on Azure today via a GitHub PR. Making that known more widely > would be good. > > For patch review, are there any of the Linux kernel bots that are well > enough documented for someone else to pick up and use? I feel like our > biggest problems are: > - Lack of reviewers in general for various areas. > - Lack of feedback to users (developers) before being picked up for > general changes. > > For the second problem, I feel like some of the Linux bots would be a > little helpful, but probably require some tweaking (figure out when / > how to fire off more limited CI, or just do a daily CI run vs every > patch, given the size of our CI build). > Don't have details but patchwork should support (somehow) to run some checks. Here you can see it working. http://patchwork.ozlabs.org/project/devicetree-bindings/patch/1594676120-5862-7-git-send-email-prabhakar.mahadev-lad...@bp.renesas.com/ or http://patchwork.ozlabs.org/project/devicetree-bindings/patch/20200713132927.24925-2-abai...@baylibre.com/ It means when the patch reach patchwork checks can run. Would be wonderful to get PASS/FAIL with link via email from CI loop. I don't have experience with gerrit but definitely don't like using github for contribution and prefer to use review based on emails. Thanks, Michal signature.asc Description: OpenPGP digital signature
Re: Using gerrit or github for review?
Hi all, Am 13.07.2020 um 23:03 schrieb Tom Rini: On Mon, Jul 13, 2020 at 10:12:32PM +0200, Wolfgang Denk wrote: Dear Simon, In message you wrote: I have used various tools and I'm wondering whether having another option might have some benefits in terms of productivity, automation and accessibility. Just as one example, if people pushed patches to github / gitlab then we could 1) check out the branch and try it, 2) have test automation attached, 3) use a UI for review. As for automation, you know that Heiko has been using tbot for years for automatic patch series download from patchwork, checking and testing (checkpatch, build, install, boot)? Perhaps this is the time we need to figure out what's missing from tbot automation and related tooling and get things integrated well between tbot, test/py/ testing we have and other ad-hoc tooling. Yes, but downloading patches from patchwork is missing in the new tbot implementation yet... but it worked for me very well ... I think, I made a video on youtube... ah yes: https://www.youtube.com/watch?v=ZwUA0QNDnP4=55s but without any comment, so not very good to follow the log, may with lower speed... The video starts where I download the patches from my Patchwork ToDo list and apply them to current U-Boot code, build and install U-Boot (here for the smartweb board) and do tests on U-Boots commandline ... If finished, pushed the result to a db... The new implementation misses currently only the step "download patches from Patchwork ToDo list" [1] which should take not much effort to reimplement. The new tbot already can handle git trees [2] and so can apply patches to it. Of course tbot can configure/build/install U-Boot [3] and call test.py [4] and push results to a DB [5]. For a demo I do this once a day currently here: http://xeidos.ddns.net/ubtestresults/home for at least 4 boards (I am happy to get more testreports! You do not necessarily need tbot for it ...) Also, of course, tbot can do a "git bisect" [6] so may you can find out, which patch breaks ... As tbot is a commandline tool, of course you can start tbot from gitlab CI runner, jenkins, buildbot,... I tried to start tbot from a travis build, but did not find (yet) a way to connect from the travis builder over ssh to a lab, where the boards under test are located ... Note: The main purpose of tbot is to help a developer while his daily work, and if you use it for your daily work, you automatically have a setup ready for starting from a CI ... I personally use the minimal way, and call tbot from a small python script (cron job like) [7] bye, Heiko [1] old tbot "download patches from patchwork ToDo list" testcase: https://github.com/hsdenx/tbot/blob/master/src/tc/linux/tc_workfd_get_patchwork_number_list.py [2] http://tbot.tools/modules/tc.html#git [3] http://tbot.tools/modules/tc.html#u-boot [4] http://tbot.tools/modules/tc.html#u-boot-test-py [5] https://github.com/EmbLux-Kft/tbot/blob/devel/generators/push-testresult.py Not mainline yet, experimental state! [6] http://tbot.tools/modules/tc.html#tbot.tc.git.GitRepository.bisect [7] https://github.com/EmbLux-Kft/tbot-tbot2go/blob/devel/minimal-ci.py config: https://github.com/EmbLux-Kft/tbot-tbot2go/blob/devel/minimal-ci.json -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: Using gerrit or github for review?
Hi, On Mon, Jul 13, 2020 at 12:25:42PM -0600, Simon Glass wrote: > At present U-Boot uses the mailing list for patch review. What do > people think about trying out geritt or github for this? I'd be > willing to do a trial with the -dm mailing list. This is both my first message to the mailing list and my first email sent using mutt. I'm hoping to eventually participate with patches and reviews but the mailing-list-driven developement model has been a barrier for myself an probably many others. I'm slowly trying to climb over it now but some will never find the time. Perhaps a good question is: How long does it take to learn the mailing-list workflow vs the github workflow? If u-boot was using github, I would have contributed long ago and I suspect there are others in the same bucket. Thats my perspective at least :) Cheers, Corey
Re: Using gerrit or github for review?
On Mon, Jul 13, 2020 at 10:12:32PM +0200, Wolfgang Denk wrote: > Dear Simon, > > In message > you > wrote: > > > > I have used various tools and I'm wondering whether having another > > option might have some benefits in terms of productivity, automation > > and accessibility. Just as one example, if people pushed patches to > > github / gitlab then we could 1) check out the branch and try it, 2) > > have test automation attached, 3) use a UI for review. > > As for automation, you know that Heiko has been using tbot for years > for automatic patch series download from patchwork, checking and > testing (checkpatch, build, install, boot)? Perhaps this is the time we need to figure out what's missing from tbot automation and related tooling and get things integrated well between tbot, test/py/ testing we have and other ad-hoc tooling. -- Tom signature.asc Description: PGP signature
Re: Using gerrit or github for review?
On Mon, Jul 13, 2020 at 12:25:42PM -0600, Simon Glass wrote: > Hi, > > At present U-Boot uses the mailing list for patch review. What do > people think about trying out geritt or github for this? I'd be > willing to do a trial with the -dm mailing list. > > My idea is that patman would email out the patches and also upload > them to one of these systems. With geritt, emails are sent every time > there is a review, but for github I'm not sure. As you said, you also intended to include gitlab in the list. So, things that I think could be better, or more widely known, would be how to trigger Azure CI runs (as there's good resources available for free) and GitLab for non-custodians. By which I mean, anyone can get a CI run on Azure today via a GitHub PR. Making that known more widely would be good. For patch review, are there any of the Linux kernel bots that are well enough documented for someone else to pick up and use? I feel like our biggest problems are: - Lack of reviewers in general for various areas. - Lack of feedback to users (developers) before being picked up for general changes. For the second problem, I feel like some of the Linux bots would be a little helpful, but probably require some tweaking (figure out when / how to fire off more limited CI, or just do a daily CI run vs every patch, given the size of our CI build). -- Tom signature.asc Description: PGP signature
Re: Using gerrit or github for review?
Dear Simon, In message you wrote: > > I have used various tools and I'm wondering whether having another > option might have some benefits in terms of productivity, automation > and accessibility. Just as one example, if people pushed patches to > github / gitlab then we could 1) check out the branch and try it, 2) > have test automation attached, 3) use a UI for review. As for automation, you know that Heiko has been using tbot for years for automatic patch series download from patchwork, checking and testing (checkpatch, build, install, boot)? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Far back in the mists of ancient time, in the great and glorious days of the former Galactic Empire, life was wild, rich and largely tax free. - Douglas Adams, _The Hitchhiker's Guide to the Galaxy_
Re: Using gerrit or github for review?
Hi Wolfgang, On Mon, 13 Jul 2020 at 14:07, Wolfgang Denk wrote: > > Dear Simon, > > In message > you > wrote: > > > > At present U-Boot uses the mailing list for patch review. What do > > people think about trying out geritt or github for this? I'd be > > willing to do a trial with the -dm mailing list. > > Speaking just for me, I never was able to make friends with either > of these. Good old mailing list is still my preference. > > > My idea is that patman would email out the patches and also upload > > them to one of these systems. With geritt, emails are sent every time > > there is a review, but for github I'm not sure. > > Also, given that the U-Boot repositories are hosted on a gitlab > server, would it not be much more natural to look for gitlab > features to use? Yes sorry I meant to include gitlab in the list but see that I didn't. So gerrit, github and gitlab. Regards, Simon
Re: Using gerrit or github for review?
Dear Simon, In message you wrote: > > At present U-Boot uses the mailing list for patch review. What do > people think about trying out geritt or github for this? I'd be > willing to do a trial with the -dm mailing list. Speaking just for me, I never was able to make friends with either of these. Good old mailing list is still my preference. > My idea is that patman would email out the patches and also upload > them to one of these systems. With geritt, emails are sent every time > there is a review, but for github I'm not sure. Also, given that the U-Boot repositories are hosted on a gitlab server, would it not be much more natural to look for gitlab features to use? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I usually tell my classes "if you are using @ and [] together in this class, you will almost certainly NOT get what you want. That's going down the wrong tunnel. There's no cheese at the end of that tunnel." -- Randal L. Schwartz in <8czptuomey@gadget.cscaper.com>
Re: Using gerrit or github for review?
Hi Heinrich, On Mon, 13 Jul 2020 at 13:36, Heinrich Schuchardt wrote: > > On 13.07.20 20:25, Simon Glass wrote: > > Hi, > > > > At present U-Boot uses the mailing list for patch review. What do > > Currently we are using Patchwork to keep track of the review process: > > https://patchwork.ozlabs.org/project/uboot/list/ > > > people think about trying out geritt or github for this? I'd be > > willing to do a trial with the -dm mailing list. > > > > My idea is that patman would email out the patches and also upload > > them to one of these systems. With geritt, emails are sent every time > > there is a review, but for github I'm not sure. > > Do we need an new tool? Managing reviews it supported by Gitlab. > > There is no need for patman in a process with any of the mentioned > tools. Gitlab, Gerrit, and Github send out mails to reviewers. > > The work flow with Gitlab and Gerrit that I have seen relied on a role > concept where only specific users of the system are reviewers. - Our > current process allows anybody to review. This is what I would like to keep. > > Simon, could you, please, explain why you want to change the current > process. I have used various tools and I'm wondering whether having another option might have some benefits in terms of productivity, automation and accessibility. Just as one example, if people pushed patches to github / gitlab then we could 1) check out the branch and try it, 2) have test automation attached, 3) use a UI for review. So that is the purpose of my email. Regards, Simon
Re: Using gerrit or github for review?
On Mon, Jul 13, 2020 at 09:45:27PM +0200, Stefano Babic wrote: > Hi Simon, > > On 13.07.20 20:25, Simon Glass wrote: > > Hi, > > > > At present U-Boot uses the mailing list for patch review. What do > > people think about trying out geritt or github for this? I'd be > > willing to do a trial with the -dm mailing list. > > > > My idea is that patman would email out the patches and also upload > > them to one of these systems. With geritt, emails are sent every time > > there is a review, but for github I'm not sure. > > > > If I remember well, we already had this discussion some years ago. One major > point against these tools is the workflow for most developers here, that is > mainly mail-centric (and shell driven instead of browser driven). Mailing > list allows to everybody to add contribute, and patches with their history > is archived in patchwork. Patches can be loaded and applied with shell tools > (pwclient). I would prefer to add some missing features to patchwork (for > example, automatic support for patches version) else to switch to another > tool that is just browser driven. With respect to patchwork tooling, there's more stuff possible these days than a while ago I believe. I got https://lists.ozlabs.org/pipermail/patchwork/2020-July/006672.html as a reply the other day and I need to go script that in to my automatic state updater as the problem was how v1/v2/etc stuff hashes the same sometimes, but that'll fix it. -- Tom signature.asc Description: PGP signature
RE: Using gerrit or github for review?
Hi Heinrich, > -Original Message- > From: U-Boot On Behalf Of Heinrich Schuchardt > Sent: Monday, July 13, 2020 10:36 PM > To: Simon Glass ; U-Boot Mailing List > > Cc: Tom Rini ; Bin Meng ; Masahiro > Yamada > ; Marek Vasut ; Vignesh > R ; > Michal Simek ; Igor Opaniuk > ; Heiko Schocher > ; Fabio Estevam ; Jagan Teki > > Subject: Re: Using gerrit or github for review? > > On 13.07.20 20:25, Simon Glass wrote: > > Hi, > > > > At present U-Boot uses the mailing list for patch review. What do > > Currently we are using Patchwork to keep track of the review process: > > https://urldefense.com/v3/__https://patchwork.ozlabs.org/project/uboot/list/__;!!A4F2R9G_pg!M278QbuG4g > 5GiXV1lWK3mAP9aDJsCGRoLe1F_6XLKUSPb0lwIfYEVIdA5gU-HTUX$ > > > people think about trying out geritt or github for this? I'd be > > willing to do a trial with the -dm mailing list. > > > > My idea is that patman would email out the patches and also upload > > them to one of these systems. With geritt, emails are sent every time > > there is a review, but for github I'm not sure. > > Do we need an new tool? Managing reviews it supported by Gitlab. > > There is no need for patman in a process with any of the mentioned > tools. Gitlab, Gerrit, and Github send out mails to reviewers. > > The work flow with Gitlab and Gerrit that I have seen relied on a role > concept where only specific users of the system are reviewers. - Our > current process allows anybody to review. This is what I would like to keep. Well anybody (I guess registered to the given instance users) may do a code-review, but only limited amount of people may vote for/against that change and then even fewer people may press the "merge" button. But in case of U-Boot only a tree maintainer may accept patches so that's OK. What is not clear for me if and how multi-level source trees might be implemented in either system. I mean so that the platform maintainer accepts a patch for this particular platform, then sends a PR to the upstream say arch maintainer and then arch maintainer sends PR to the Tom. -Alexey
Re: Using gerrit or github for review?
Hi Simon, On 13.07.20 20:25, Simon Glass wrote: Hi, At present U-Boot uses the mailing list for patch review. What do people think about trying out geritt or github for this? I'd be willing to do a trial with the -dm mailing list. My idea is that patman would email out the patches and also upload them to one of these systems. With geritt, emails are sent every time there is a review, but for github I'm not sure. If I remember well, we already had this discussion some years ago. One major point against these tools is the workflow for most developers here, that is mainly mail-centric (and shell driven instead of browser driven). Mailing list allows to everybody to add contribute, and patches with their history is archived in patchwork. Patches can be loaded and applied with shell tools (pwclient). I would prefer to add some missing features to patchwork (for example, automatic support for patches version) else to switch to another tool that is just browser driven. Best regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
Re: Using gerrit or github for review?
On 13.07.20 20:25, Simon Glass wrote: > Hi, > > At present U-Boot uses the mailing list for patch review. What do Currently we are using Patchwork to keep track of the review process: https://patchwork.ozlabs.org/project/uboot/list/ > people think about trying out geritt or github for this? I'd be > willing to do a trial with the -dm mailing list. > > My idea is that patman would email out the patches and also upload > them to one of these systems. With geritt, emails are sent every time > there is a review, but for github I'm not sure. Do we need an new tool? Managing reviews it supported by Gitlab. There is no need for patman in a process with any of the mentioned tools. Gitlab, Gerrit, and Github send out mails to reviewers. The work flow with Gitlab and Gerrit that I have seen relied on a role concept where only specific users of the system are reviewers. - Our current process allows anybody to review. This is what I would like to keep. Simon, could you, please, explain why you want to change the current process. Best regards Heinrich
RE: Using gerrit or github for review?
Hi Simon, > -Original Message- > From: U-Boot On Behalf Of Simon Glass > Sent: Monday, July 13, 2020 9:26 PM > To: U-Boot Mailing List > Cc: Tom Rini ; Bin Meng ; Masahiro > Yamada > ; Heinrich Schuchardt ; > Marek Vasut > ; Vignesh R ; Michal Simek > ; Igor > Opaniuk ; Heiko Schocher ; Fabio > Estevam ; > Jagan Teki > Subject: Using gerrit or github for review? > > At present U-Boot uses the mailing list for patch review. What do > people think about trying out geritt or github for this? I'd be > willing to do a trial with the -dm mailing list. > > My idea is that patman would email out the patches and also upload > them to one of these systems. With geritt, emails are sent every time > there is a review, but for github I'm not sure. From my experience Gerrit's code-review interface is much less human-friendly as compared to GitHub. Also GitHub has "Issues" which are nicely integrated with "Pull-requests". One good example you may look at is Zephyr RTOS, see https://github.com/zephyrproject-rtos/zephyr/. They do use GitHub features quite extensively. But given U-Boot git repos are already hosted in GitLab instance why not consider it instead of either GitHub or Gerrit? Review and issues are already there as well as some other fancy features. Or I'm missing the main point of the question? -Alexey
Using gerrit or github for review?
Hi, At present U-Boot uses the mailing list for patch review. What do people think about trying out geritt or github for this? I'd be willing to do a trial with the -dm mailing list. My idea is that patman would email out the patches and also upload them to one of these systems. With geritt, emails are sent every time there is a review, but for github I'm not sure. Regards, Simon
