Re: to PR or not to PR, is /that/ the question?
Hi, On Thu, 14 Sept 2023 at 08:53, Giovanni Biscuolo wrote: > To remain /in topic/: I think that adopting a «web based PR model» will > definitely _not_ decrease the cognitive overhead for contributors. What could potentially decrease the cognitive overhead for contributors when using a "web based PR model" is all the usual glue (services) around this very same "web based PR model". Somehow, the discussion is about these services behind the web-button. I agree with Katherine, quoting [1]: I know everyone is focusing on email vs. web-forge, but I am trying to draw attention to the root causes of the complexity, and enumerating possible solutions to these. IMHO, I think we have identified some of these causes of complexity. Last, let me say it again: I am perfectly happy with the email workflow. :-) Cheers, simon 1: Re: How can we decrease the cognitive overhead for contributors? Katherine Cox-Buday Tue, 05 Sep 2023 13:15:48 -0600 id:13416fee-8c7d-b145-48b9-0fbec2251...@gmail.com https://lists.gnu.org/archive/html/guix-devel/2023-09 https://yhetil.org/guix/13416fee-8c7d-b145-48b9-0fbec2251...@gmail.com
Re: to PR or not to PR, is /that/ the question?
Hi Simon Simon Tournier writes: > Thank you for your detailed message. Sorry, I have not read all the > details because I have been lost. Sorry! Forgive me since I am not able to summarize the details without losing content. > What do you want to explain? In the context of this increasing cognitive overheading thread... As I wrote: «I don't think thay adopting a «web based PR model» (whatever the term "pull request" means, editor note) for the Guix project is a good idea.» To remain /in topic/: I think that adopting a «web based PR model» will definitely _not_ decrease the cognitive overhead for contributors. Also, replacing (or adding to) the current "integration request" email based workflow with a "web based PR model" (that _imply_ a web based patch review strictly connected with the choosen "forge"?) would be an /overwelming/ cognitive overhead for all. Last but not least, I also think that adding a patch review system like Gerrit or Gerrit, Phabricator, and Review Board would not only _increase_ the overall cognitive overhead but is also /technically/ _broken_. Why I think all this things? Well, I'm sorry but it's a _very_ long story and is all written down in the /details/. (id:87y1ha9jj6@xelera.eu aka https://yhetil.org/guix/87y1ha9jj6@xelera.eu/) [...] I'm done with this thread, sorry; I'll drift alone :-) Happy hacking, Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: to PR or not to PR, is /that/ the question?
Hi Giovanni, Thank you for your detailed message. Sorry, I have not read all the details because I have been lost. What do you want to explain? Well, let me explain my understanding using my own words. :-) When one reduces to the core of the workflows, the main difference between “email workflow” and “PR workflow” is the way the submitter sends the code to the reviewer. 1. email workflow: the diff are sent by email. 2. PR workflow: the diff are sent by the VCS itself. Then, we can put a lot of glue around these workflows. It is possible to work in a centralized fashion or in a distributed fashion. It is possible to use a proprietary service for delegating some parts using a button via a web-interface. It is possible to have a service based on free software that automatize some parts of the workflow. Etc By glue, it reads a range from mailing list to Github, or from Gitlab to Sourcehut, or from personal custom scripts to tools as B4, public-inbox, Gerrit, patchwork, etc. Obviously, the PR workflow also depends on the features of the underlining VCS when the email workflow not. Bitbucket provided a PR workflow for Mercurial. And a PR workflow would be hard to implement using Subversion or worse using CVS. Note that the email workflow #1 might be centralized. That’s what we are doing when using one mailing list; there is only one unique location for exchanging all pieces of code. Or it might be decentralized, that’s how the contributors send their contribution to some linux kernel maintainers. Note that the PR workflow #2 might be decentralized. That’s more or less how Linus Torvald’s “lieutenants” are doing for asking a merge in the Linus’s mainline linux kernel. Or it might centralized and web-forges provide many examples. :-) The requirement for #1 is just being able to send emails. The requirement for #2 is to have a public Git repository. Both workflows have pros and cons. And then these pros and cons also depend on how the workflow is implemented. And none is not much better than the other. The slight difference between the two is the state of the contribution from the reviewer perspective: . About the email workflow #1, the patches might not apply for many reasons but because they are sent by email, the notification “hey give a look to thing” and the “diff for thing“ are synchronized. . About the PR workflow #2, the patches belong to a Git repository so they are already applied. However, between the notification “hey give a look to thing” and the moment when the reviewer pulls the thing, the Git repository might disappear, be replaced, history rewritten, etc. Well, that’s my understanding of the difference between #1 and #2. A bit simplified but it captures my understanding of the main, I guess. :-) Cheers, simon
to PR or not to PR, is /that/ the question?
Hi Simon, please forgive me if I continue drifting in this beautiful sea... This message is /very/ long but it's just because I'm trying to do my best to provide a deep analisys of the **big** problems with eventually adopting a «web based PR model» (please see below for a definition) for contributions to Guix. Please skip this if you don't have enough time to drift like I'm doing! Also, please consider I don't have much experience on how a «web based PR model» works and /doesn't work/ in practice... but I'm studying :-) Simon Tournier writes: [...] > This branch of the long thread starts with: > > Re: How can we decrease the cognitive overhead for contributors? > Attila Lendvai > Fri, 25 Aug 2023 08:07:53 + > > id:JRUs8LVm3AtAh0MnHjE5rnhB4sNET0vWTOO2N3w2KfvKoM3CALRNwHTmwJ0Y9Bg3ZDWCs8j-1bMCo9aRiaoac8TAkuXAvrWgSwt_8RcwhQA=@lendvai.name > > https://yhetil.org/guix/JRUs8LVm3AtAh0MnHjE5rnhB4sNET0vWTOO2N3w2KfvKoM3CALRNwHTmwJ0Y9Bg3ZDWCs8j-1bMCo9aRiaoac8TAkuXAvrWgSwt_8RcwhQA=@lendvai.name > https://lists.gnu.org/archive/html/guix-devel/2023-08 > > Attila speaks about the PR model. Actually he is speaking about «the web based PR model». I don't want to sound pedantic, but [1]: --8<---cut here---start->8--- It's worth noting that the term pull request is not universally used: GitLab calls them merge requests for example. Furthermore I regard the terms pull request and merge request to be poorly named, as the terms can be conflated with terminology used by your version control tool (e.g. git pull or git merge). And the implementations of a pull or merge request may not even perform a pull or a merge (you can also rebase a pull/merge request, but nobody is calling them rebase requests). A modern day pull request is so much more than a version control tool operation or even a simple request to pull or merge a branch: it is a nexus to track the integration of a proposed change before during and after that change is integrated. --8<---cut here---end--->8--- Please let me underline: PR it's *a* nexus, one of the different one available with a DVCS. With git, for example, we also have "git request-pull", with it's email based workflow. --8<---cut here---start->8--- But alas. Because GitHub coined the term and is the most popular collaboration platform implementing this functionality, I'll refer to this general workflow as implemented on GitHub, GitLab, Bitbucket, and others as pull requests for the remainder of this post. [...] At its core, the pull request is fundamentally a nice UI and feature layer built around the common Git feature branch workflow. --8<---cut here---end--->8--- As I tried to tell elsewhere, all so called "pull request" features incorporated in various "web based forges" are just /user interfaces/ built around the Git feature branch workflow. ...and guess what: Guix _is_ implementing a Git feature branch workflow [2]! Guix is also starting to use a clever "request merging" workflow, integrated with qa.guix.gnu.org [3], see https://issues.guix.gnu.org/65846 as an example. Guix is just not implementing a feature branch workflow to incorporate _commits_ coming from the contributors, and I still think this is wise. Furthermore: --8<---cut here---start->8--- [...] I think it is time for industry to scrutinize the pull request model and to evolve it into something better. I know what you are thinking: you are thinking that pull requests work great and that they are popular because they are a superior model compared to what came before. These statements - aside from some nuance - are true. But if you live in the version control space (like I do) or are paid to deliver tools and workflows to developers to improve productivity and code/product quality (which I am), the deficiencies in the pull request workflow and implementation of that workflow among vendors like GitHub, GitLab, Bitbucket, etc are obvious and begging to be overhauled if not replaced wholesale. [...] In other words, the way I see the world is that a specific vendor's pull request implementation is just that: an implementation detail. And like all implementation details, they should be frequently scrutinized and changed, if necessary. --8<---cut here---end--->8--- The rest of the article is worth reading since it is a professional analisys of the problems with "Pull Requests" /implementations/ and workflow, backed by some (sort of?) research: --8<---cut here---start->8--- [...] the current implementation of pull requests actively discourages the many smaller changes workflow. And since smaller changes result in higher quality and faster reviews, today's implementations of pull requests are undermining
