[OE-core] Patch merge process

[Martin Jansa]

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?

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.

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"

* 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

> 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).

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)

> 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.

Cheers,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150901/8ff4a07d/attachment-0002.sig>