[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 <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
- Mumi, public-inbox and tools, zimoun, 2022/05/02
- Re: Mumi, public-inbox and tools, Arun Isaac, 2022/05/03
- Re: Mumi, public-inbox and tools, zimoun, 2022/05/04
- Re: Mumi, public-inbox and tools, Ludovic Courtès, 2022/05/07
- Re: Mumi, public-inbox and tools, Arun Isaac, 2022/05/08
- Re: Mumi, public-inbox and tools,
zimoun <=
- Re: Mumi, public-inbox and tools, Ricardo Wurmus, 2022/05/10
- Re: Mumi, public-inbox and tools, Ludovic Courtès, 2022/05/15
- Re: Mumi, public-inbox and tools, zimoun, 2022/05/08
- Re: Mumi, public-inbox and tools, Maxime Devos, 2022/05/09