Hi Arun,
On Sun, 08 May 2022 at 11:43, Arun Isaac <arunis...@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-patc...@gnu.org"
:listid "guix-patc...@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....@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
