[OE-core] Patch workflow [was: meta/recipes-core/base-passwd/base-passwd/noshadow.patch: Split it into two parts]

Laszlo Papp lpapp at kde.org
Sat Feb 8 21:56:28 UTC 2014


On Sat, Feb 8, 2014 at 12:20 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Sat, 2014-02-08 at 12:07 +0000, Laszlo Papp wrote:
>> Why is it a nightmare? For instance, maintainers in other projects
>> leave a "Pushed, thanks" note.
>>
>> See how much discussion this generates already, instead of two words.
>> While you are at the change to merge it, you are already in place to
>> leave the comment. However, contributors need to go and find the
>> corresponding url, etc. Please note that contributors may want to know
>> whether their voluntary work got merged without even a checkout, for
>> instance double checking from mobile, etc.
>>
>> ... or is the real problem the lack of maintainer man power?
>
> Its both a man power problem and the process isn't as simple as
> described.
>
> The changes get batched together into large units, those get tested on
> the autobuilder. If they work out ok, the changes go in, if they fail,
> we pull out patches until we get a successful batch, then merge.
>
> Upon failures, we do aim to mention those on list. Having to go back
> through emails to find the ones which merge and "ack" them is a pain
> though since we are "not already in place" as you put it.

Hmm, that is unfortunate, and practically speaking: having contributed
to several projects, it is also a bit outstanding. It feels like the
tools do not do the ideal job.

> There are only two people in general who do this on OE-Core, myself and
> Saul. We do have a ton of other pressures on our time, we do the best we
> can. If someone wants to ack patches that merge I'm happy for them to do
> so, it would be just as much work for them as it would for me/Saul.
>
> I am aware there are patch management tools out there which can show
> status of patches. We've looked hard at them and in general they impose
> more overhead and process onto people who don't want it.

OK, can you please elaborate about the drawback of e.g. Gerrit?

I was told before that it would not have the feature of off-line
reading while flying on an airplane. Is this really such a common
scenario for Yocto maintainers, or there are other reasons? I would
imagine managers travel a lot more than maintainers. :-)

Have you (Intel, Linux Foundation, etc) considered improving the existing tools?



More information about the Openembedded-core mailing list