[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On commit access, patch review, and remaining healthy

From: zimoun
Subject: Re: On commit access, patch review, and remaining healthy
Date: Tue, 21 Jun 2022 17:44:27 +0200

Hi Hartmut,

On Mon, 20 Jun 2022 at 14:53, Hartmut Goebel <> 

>          my system is set up to emacs could send out mails.

Well, if you are already using Emacs, the Emacs front-end is not the
nicest interface but does part of the job.  I have this:

--8<---------------cut here---------------start------------->8---
   debbugs-gnu-default-packages '("guix-patches")
   gnus-summary-line-format "%I%(%[ %n%]%) %s\n")
--8<---------------cut here---------------end--------------->8---

Then ’M-x debbugs-gnu’.  Yeah, I agree it is a bit slow. :-)

> I tried debbugs from time to time and for me it is disgusting:
>   * too complicated to get to the list of patches or bugs ( I never can
>     remember the many key-presses to perform) ,

To me, the annoyance comes from that ’M-x debbugs-gnu-bugs RET’ returns
the 10 last submissions but it is for the whole GNU project; when I
would like to filter only ’guix-patches’ or ’guix’.

>   * I did not manage to apply patches from there (emacs would need to
>     know where my guix development directory is - how can I tell it?)
>   * commands withing debbugs feel complicated
>   * if a ticket contains several updated patches, its very hard to find
>     those relevant (one of the reasons of forges' success is that they
>     present you the current state)

Well, submitter should use ’git format-patch --reroll-count’. )-:

>   * actually testing the patches required to apply the patches to my
>     worktree - and chances are high 'git am' will fail with some
>     conflict - chances raise extremely for old patches

Again, submitter should use ’git format-patch --base’; as specified by
the manual. :-)  Using this ’base-commit’, you know where the patch
applies and so you can checkout against the right correct.

>   * Over all for me debbugs.el needs a much more "noops"-friendly
>   interface

Well, I think ’public-inbox’ could help.  An instance is:

where using lei, you can filter and receive to your inbox the patches.
For example, ’lei’ allows to filter (and thus follow), e.g., let query
for the patches submitted the last 3 months to
’gnu/packages/bioinformatics.scm’ touching R packages,

dfn:gnu/packages/bioinformatics AND b:r-build-system AND rt:3.months.ago..


   dfn:     match filename from diff
   b:       match within message body, including text attachments
   rt:      match date-time range, git "approxidate" formats supported
            Open-ended ranges such as `d:last.week..' and `d:..2.days.ago'
            are supported


Then, ’lei up’ will request the public-inbox server for this query and
will download the messages if any.  Therefore, you can filter and
receive only the patches that interest you.  Then you could save such
patches and apply them using ’git am’.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]