[OE-core] Patchwork & patch handling improvements
akuster808
akuster808 at gmail.com
Fri Nov 27 17:15:39 UTC 2015
Paul,
On 11/26/2015 01:00 PM, Paul Eggleton wrote:
> Hi all,
>
Thanks for taking the time to look into this.
> 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.
This is not all the result of the patchwork. As a maintainer I rarely
use the patchwork in work flow as I have no access to the state change
bits. So its harder to integrate patchwork into my workflow.
Since the rules are to wait for changes to hit Master before moving them
down the line adds time to merging patches to the stable branches. The
Patchwork does not have an impact on that delay.
What adds to the challenge of integrating patches is that a layer
maintainer may shoot a patch directly into the stable branch so if I had
that patch queued, I now have to back it out.
Also, I do this work all on my free time so I do my work in batches with
leads to some delay. I could probably do a better job at communication
where things are in the process.
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.
Yes please.
>
> 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].
sounds good.
>
> 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.
Yes, I would like to use this with meta-oe
>
> 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.
>
Yes we should enhance any tools that improve our workflow and quality of
work.
Kind regards and thanks again Paul.
armin
> [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
>
More information about the Openembedded-core
mailing list