Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing - Summary of discussion so far

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

Hi all,

given this was a fairly lengthy thread, I thought I'd summarize. Although I 
originally thought the proposal was uncontroversial, Jan has raised some 
concerns about extra e-mails that would be sent by the patch bot (aka 1 
additional mail per series). From the discussion, I got the sense that Jan's 
objection was a -1, not a -2. One of the main concerns Jan raised was about 
extra mail generated for small single file patch series.

With this in mind, the sensible way forward would be to go ahead with the plan 
(see below). If Jan (and others) believe this generates too much spam, we can 
add a "do-not-mail" list of e-mail addresses that the bot will avoid sending 
mail to. If there's a series someone in the "do-not-mail" list decides they 
want information on, it shouldn't be too difficult to find it from the status 
page. Alternatives may be to revisit items 3 and/or 5 (see below).

Regarding next steps, Doug and Wei will continue working on this and we will 
first set up all the mechanics (aka patchwork instance connected to GitLab) 
without sending mails until we are confident it works.

Once this is done, the preference (based on feedback to the thread so far) 
would be towards the following user visible behaviour:

1: Do we trigger a CI cycle for *every* series posted to xen-devel?
Yes, assuming we have enough compute resources to implement this
We would only do this for series that apply to xen.git - it may make sense for 
the Unikraft team to have a chat with Doug/Wei though to see whether they can 
mirror what we are planning to do for xen.git

2: Do we have an opt-in or op-out (e.g. through a tag, a specific CC, etc.) for 
series
Opt-out: the UI for that would need to be agreed

3: Do we report results back to xen-devel or to a separate list
Report back to xen-devel@ 
One reply per series to the cover letter for multi-patch series and to the 
single patch for single patch series

5: Do we report back on success or only on failure?
On success AND failure (note that QEMU only does this on failure only)

4: Who else, besides the author should get a mail
Reply-to-all

6: What exactly do we report back
A link to the git branch it created (if the patch applied), or a snippet of the 
rejection message if it didn't.
Success / failure, with a link to a page containing the various tests run, so 
people can see which one failed and investigate the failures.

There was another discussion about series which depend on each other

We could implement this via a tag such as
Prerequisite-series: <5B506A6E02000078001D5D17@xxxxxxxxxxxxxxxxxxxxxxxx>

Support for this exists in a tool called git-series (the author says he's 
working on integrating its functionality into the git upstream) that does 
exactly this.
There is a strong possibility that support for this will be included into a 
future patchwork version

We really have two choices:
a) Implement something around custom tooling based on git-series
b) Wait until support is available in patchwork

This is an open question, but my gut feeling would be to go for b) for now. If 
it takes too long, we can go for a)

Other loose ends:
* Some heuristic to identify patches for xen.git (aka excluding Linux, Qemu, 
OSSTEST patches)
* Waiting for clang-format changes from Iurii Artemenko - blocks checkpatch.pl 
support
* Discussion with Arm around some of the loose ends for Arm support (e.g. 
someone to help Wei to ensure that the containers work on Arm, access to Arm 
HW, etc.) - blocks Arm support

Please shout, if this is an inaccurate summary.

Best Regards
Lars



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel