[Top][All Lists]

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

Re: Mumi, public-inbox and tools

From: zimoun
Subject: Re: Mumi, public-inbox and tools
Date: Sun, 08 May 2022 22:59:33 +0200

Hi Arun,

On Sun, 08 May 2022 at 11:43, Arun Isaac <> 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

> 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,

         :url "";
         :address ""
         :listid ""
         :coderepo "~/src/guix/")


>> 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:


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: <>

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.


reply via email to

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