[OE-core] Patchwork & patch handling improvements

Paul Eggleton paul.eggleton at linux.intel.com
Thu Nov 26 21:00:36 UTC 2015


Hi all,

Over the past several years one of the regular complaints people have made 
about our project has been that patches sometimes take a long time to make it 
into master, and it's not always clear what the state of a patch is during 
that time. On the other side of things, maintainers are finding it increasingly 
hard to keep up with testing and integrating incoming patches. Additionally, 
trivial mistakes sometimes creep in that would be fairly easy to catch with an 
automated process. We've been talking about this for a while and now I'd like 
to propose a plan to finally address this:

1) Upgrade the OE Patchwork instance [0] to a newer release; this should fix 
some of the problems we are having [1] plus give us additional features. I 
propose using the fork that freedesktop.org are using [2] [3] which is moving 
a bit faster than upstream Patchwork; whilst the changes there may eventually 
make it upstream (and work is ongoing there) we have a much greater ability to 
influence the fork given that it's being worked on by one of my colleagues who 
is pushing it in the direction we need it to go e.g. proper support for series 
as opposed to treating every patch individually, improved UI, etc.

2) Trigger automatic testing of submitted patches from Patchwork. We'd have a 
script look at the contents of a patch and first check that the expected style 
has been adhered to; second it would do some quick tests to verify that the 
patch hasn't caused any immediately obvious regressions. I've filed some bugs 
to cover this in more detail [4].

3) Provide a means to easily schedule an overnight build on the autobuilder 
for the set of patches that have passed the initial testing, as well as 
present the results in a form that's easier to review for maintainers. For OE-
Core this would be tied into the Yocto Project autobuilder, but I expect the 
tools could be made flexible.

At all stages through this process the patch status in patchwork will be kept 
up-to-date so it's clear to everyone what's happening. I'm also thinking we 
could do email notifications to the submitter (opt-in) though that would be a 
later add-on.

Whilst the initial plan covers only OE-Core, once we get them working the 
tools and scripts used should be just as applicable to other layers. I'm also 
trying to ensure that the patch validation is generic enough so it can live in 
OE-Core, and thus we can easily update and refine it over time in line with the 
code itself as well as encourage submitters to use the script on their own 
changes before sending.

Please let me know your thoughts on the above, most importantly on the 
patchwork upgrade, since most of this hinges on that; I don't believe we can 
practically base it on the version of Patchwork we are using now. 

[Note that this email is cross-posted - it may be best to reply on OE-Core 
only to save people's inboxes.]

Thanks,
Paul

[0] http://patchwork.openembedded.org/
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=7657#c21
[2] http://patchwork.freedesktop.org/ 
[3] https://github.com/dlespiau/patchwork
[4] https://bugzilla.yoctoproject.org/show_bug.cgi?id=8648

-- 

Paul Eggleton
Intel Open Source Technology Centre



More information about the Openembedded-core mailing list