[OE-core] Patch merge process

[Khem Raj]

> On Sep 1, 2015, at 2:55 PM, Martin Jansa <martin.jansa at gmail.com> wrote:
> 
> On Tue, Sep 01, 2015 at 10:40:33AM -0700, Khem Raj wrote:
>> Hi All,
>> 
>> I thought of bringing this up for discussions, I am seeing that, in some pull requests some patches get dropped and I understand
>> that there might be a reason for that but that reason is not communicated in proposed patch mail often. I have experienced with some of the
>> pull requests myself and seen it with some others. I think we are not responding to patches as it should be. Since we follow
>> just mailing list as upstreaming process thats the only channel that developer is engaged w.r.t. patches and there should be a conclusion
> 
> Are you seeing this issues with patches sent for meta-oe and meta-qt5
> repositories as well?

Not specifically, moreover meta-openemebedded also uses patchwork, even though one way but there are updates that submitter can get through out patch flight even if there is no email conversation on mailing list.

> 
> I know sometimes it takes me long time to reply, but I'm trying to send
> failure logs or at least some information back when I'm not taking some
> patches from master-next to master or worse dropping some patch from
> master-next completely.

If its predictable thats more important, we can always work towards reducing the cycle time.

> 
> Second part of this problem is that sometimes there is no reply from
> original submitter for months, so I'm actively updating 4 branches to
> keep track of “state"

thats good and if ball is in submitter’s court then its over and you can ignore and may be mark it stale
descretion is upto maintainer if the patch is important and there are minor issues that you can fix and accept it so be it. if it
needs submitters attention and submitters doesn't follow up. Ignore it by all means.

> 
> * origin/master
> * origin/master-next (patches without terrible issues which seem to me at
>  least worth trying on my jenkins world builds - that doesn't mean that
>  there isn't NAK on ML about some other issues - but I still want to
>  build test it asap)
> * contrib/jansa/master (this is the actual branch used by jenkins builds,
>  it's rebased on top of master-next and can contain some of my
>  last-minute wip hotfixes I wanted to get into jenkins build even
>  before sending them to ML)
> * contrib/jansa/master-next-unresolved-review (dumping ground for
>  rejected patches abandoned by their submitters, when I get fed up with
>  seeing the same failure on jenkins builds and no reply from submitter
>  I move it here and partially forget about it - until new version is
>  sent and I can compare it here with older version - this branch is
>  updated only when I'm really dumping some patches

Thats good information. May be you can put it on Wiki as your patch flight process, so it can help submitters, when they have questions in this regard.


> 
>> on the mailing list itself for a given patch. So I would request to whoever along with Richard is validating the patches and bringing them to OE-Core from mailing lists to respond to the patches especially the ones that are not applied with reasons why its not applied and similarly to the ones that are applied but has been rejected by some reviewers. It would also be good to document the commit criteria somewhere, so developer can do rework and ease the pressure on maintainers. Can we explore some tools that can help here ? May be failed errors.yp.org output can be sent to list of developers whose patches has been part of staging ?
> 
> I fully agree that some tooling is needed, especially now with jenkins
> builds with 20+ failures, my intake process is greping console logs from
> all 3 jenkins worlds to see if modified component was even built, then
> greping the other report for possible new QA issues, then trying to find
> thread on ML if some reviewer reported really blocking issues (or
> something which can be easily fixed in follow-up patch) - sometimes I
> open the patch on patchwork from master-next bundle and check it there,
> because I still need to mark it as "Accepted" there - the git hook doesn't
> work for last few years (never finds anything to close).
> 

I think a tool like gerrit or phabricator might be worth exploring. Which can have multiple staging per
patch and lot of hooks. The key piece would be to tool, pre-commit start of jenkins build ideally, when a patch shows up on the tool
it can start a reduced build bitbake <changed-component>, however its a bit involved process to setup these tools


> In the end this process is very error-prone and I often need to ask a
> bit later for follow up fix for e.g. QA issues which weren't noticed,
> because in the jenkins build I was using for check they were already
> reused from sstate.
> 
> There is also small issue with errors.yp.org that many components fail
> with so big log.do_compile that whole submission is rejected (currently
> happens for qemux86* builds where webkit-efl is failing after some
> changes in oe-core)

may be a bug report for YP tinderbox.?

> 
>> I think its extremely important to keep a developer informed and engaged about the upstreaming if we want to encourage more voluntary participation in the project.
>> 
>> It would be good to identify where we have bottlenecks and how can we improve upon the situation, ideas are welcome.
> 
> I hate to say it, but for meta-oe and meta-qt5 I would like to use
> gerrit - it's great to see all related information (all revisions of the
> patch, all review comments, all results of verification builds) in
> single location from where you do the actual submissions to official
> branch when all criteria are satisfied.

I would support this, however, we need a gerrit instance setup and some volunteer to help set it up and maintain it. Any volunteers ?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150901/f052626d/attachment-0002.sig>