On Mon, Feb 05, 2024 at 10:50:36PM +0000, Steve George wrote: > Hi Hartmut, > > Apologies, my reply-to went a bit mad and I sent you empty emails :-( > > You said: > > > The current mail-based workflow is too complicated for new and > > occasional committers. This is the main reason I gave up reviewing patches. > > > > In the case of *reviewing patches* can you give some examples of: > > 1. Some patches from others you reviewed? > 2. The steps you went through to undertake that review? > > If for example, you started to review a simple update to a package how do you > aproach it? > > It would be great to hear directly from someone doing 'reviewing' on the > specifics. Apologies, if this is going over old ground. First step is choosing a package to review. I normally start with ones that are emailed to me directly as part of the rust-team. I now have an email thread with between 20 and 150 patches to review. (I start by looking through some of them manually to see if they look like they're following conventions, ie: 1 change per patch. Assuming they generally look good,) I start with the first patch and, from mutt, I pipe the patch to 'cd ~/workspace/guix; git am -S -s'. I then compare the commit message to the contents of the patch, looking at it in 'tig', a TUI git interface, and will adjust the patch and/or the commit message as necessary. Then I try to build the package(s) changed by the patch set so far. When I'm happy with how it looks I'll pipe the next patch from mutt to check out. Once I reach the end of a patch series, or after a bunch of patches, I'll look through the set I've applied to make sure I'm still happy with them as a whole (update the package and then remove it?) and then continue on. At the end, when I'm happy with it, I'll reply to the first or last email, detail a bit what changes I've made, and tell them that I've applied the patches. I then save the email in my drafts folder and move on to the next patch series I'm going to look at. At the end, after rebasing everything on top of wherever the branch moved to while I was working, I'll push my branch to Savannah and then send off the emails. If I come across a patch that I'd like changes to before committing I'll either add them inline ('v' in mutt to see the parts of the email, choose the part with the patch, 'g' to reply-all, and then add them inline), or I'll apply it and then reply to the original email with the diff ('git diff -p > ~/changes-to-XXXX.diff', attach in reply email) and some text in the header about the changes. I then throw out my local changes since they're either where I can recover it from the email or in my git stash. If I choose a package from qa.guix.gnu.org to review I'll pick one and note the number. I go to my checkout, 'git fetch --all' to refresh my checkouts¹, open it with tig, switch to the branches view (with 'r'), find the patchset (guix-patches/issue-XXXXX), and then with 'C' I'll cherry-pick all the patches from the patchset in one go. I then look them over one at at time in tig like above, and I'll make any changes to either 'squash' or 'fixup' onto specific patches later when I go over it with 'git rebase -i'. Some notes: I've never figured out how to use emacs, much less emacs and debbugs. My only interaction with debbugs is to open or close bugs; I do not know how to look at user tags, or any other tags, in debbugs, although I would guess that it might be possible from the web frontend. Similarly, I don't know if a bug has been closed by someone else, I just assume it to be so when a patch is applied or if I see it said so in an email. I use vim-fugitive (and editorconfig I guess) as my only plugin for working with git. ¹ https://git.guix-patches.cbaines.net/git/guix-patches is the location where the patchsets are stored in a git repo -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted