Re: Mumi, public-inbox and tools

[zimoun <zimon.toutoune@gmail.com>]

Hi Arun,

On Sun, 08 May 2022 at 11:43, Arun Isaac <arunisaac@systemreboot.net> wrote:
> Hi Ludo,
>
>> The attached super-early-draft ‘guix review’ script fetches mboxes from
>> mumi—that part is OK.
>
> I like the idea! But, could we put this in mumi instead of guix? That
> way, other packages that use debbugs/mumi (skribilo comes to mind), can
> benefit from it as well. Something like

Personally, I think such feature is a perfect candidate to Guix
extensions.


> Maybe, we should read some config file, say mumi.scm, from the top-level
> directory of the current git repo to determine settings (think package
> name, debbugs/mumi web URI, post-processing function to provide feedback
> about the patch, etc.) specific to that repo.

I agree that it deserves a config file.  For instance, piem [1] uses
something like,

        ("guix"
         :url "https://yhetil.org/guix"
         :address "guix-patches@gnu.org"
         :listid "guix-patches@gnu.org"
         :coderepo "~/src/guix/")

1:
<https://docs.kyleam.com/piem/Registering-inboxes.html#Registering-inboxes>


>> What’s more difficult is the rest: determining what’s a patch and what’s
>> not (I gather this is something that b4 and Patchwork handle nicely),
>> getting the latest patch series, things like that.
>
> At some point, we should patch mumi to determine these. Determining the
> latest patch series shouldn't be hard if we use the Date
> header. guile-email will let us read any email header.

Well, I think the general case is not easy.  For an example of a complex
thread and patch submission, consider this one:

    <https://yhetil.org/guix/cu7pnfaar36.fsf@systemreboot.net/#r>

I have not tried to use B4 [2] on that one though.  Somehow, I am not
convinced that the Date header would be enough to identify the last
patches.  For instance, the first submission is a patch attached, then
the others are inline, then comments are interleaved, etc.

2: <https://git.kernel.org/pub/scm/utils/b4/b4.git/about/>


IMHO, this determination requires some work. :-)

That’s said, we could also agree that “mumi review” would only work when
a set of rules (inline patches, base-commit, etc.) are applied.  And for
the other cases, the current manual patches application would be used.

Somehow, constraint a set of rule would ease the automation and it
appears to me an acceptable trade-off: it helps such automation and the
work by reviewer and in addition we can still deal with the submissions
not respecting such rules by reusing the “laborious” current method.


Cheers,
simon