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 <efr...@flashner.co.il> רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
