Once a patch has passed basic testing, the next step is to gather it up with other patches that have also passed and assemble them into a branch (or set of branches if multiple repos are involved) that can be tested. If there are conflicts then as many of the patches that can be applied together should go into the branch and then an email should be sent to one or more maintainers in order to either resolve the conflicts manually and push the branch, or throw the patch(es) back to the submitter(s) for them to refresh.
Damien has pointed me to https://github.com/mhagger/git-imerge which may (or may not) be helpful for this.
As noted on bug 8714 we need to take care to preserve the link between commits in the branch and entries in patchwork; these links should survive rebasing / modification by the maintainer should they choose to do that.
M1 missed. Practically the same comment as https://bugzilla.yoctoproject.org/show_bug.cgi?id=8648#c7 applies on this bug. I am working on adding features into git-pw, so we can get patches/series, apply them into poky and proceed with the testing.
M2 missed. Focused on the development of patchtest [1] during M2. patchtest will be used for this purpose (patch assembling and testing) but right now is not ready to do that, so M3 should be time to implement it. [1] https://github.com/lsandoval/patchtest
Moved to 2.1M4. M4 does not accept enhancements, but this is not a poky enhancement; Setting it to M4 give some time to fully completed it. Current progress: 60%
(In reply to comment #5) > Moved to 2.1M4. M4 does not accept enhancements, but this is not a poky > enhancement; Setting it to M4 give some time to fully completed it. Current > progress: 60% Even though this is not a poky enhancement we need to check for its inclusion into an M4 with CCB.
Michael, another bug that once the PW instance is ready, you can assign it back to me.
Blocked on Patchwork upgrade.
Now that new pw instance is up, I need to test it with latest patchtest/patchtest-oe tools.
One of the main changes of patchtest during M1 is that now only a single patch can be tested; in the past, one or more patches can be used as input but this turned into much more complexity into the code. Using a single patch as input and indicating patchtest to keep its working branch after testing, it fulfill the same feature as before. As 8648, this needs to be tested during M2 window with new series (new series coming into patchwork). All related code is implemented, it just needs testing.
All new logic implemented but not tested. As mentioned in previous comment, a big refactor was made but still it has not been tested after it. Bug on track for M2.
The script has been briefly reviewed by Paul E. and he agreed the approach. Code is still not public but the approach consisted in creating a script which accepts one or more mboxes, use patchtest to test it and then try to git-am into a particular branch. Patches are merged base on the creation time, oldest first (FIFO) newest last; results are stored as git-notes, so these can be easily shared to upstream repos so other tools can use this data. Script is still not documented, so augmenting the README with this info. One more thing: git-imerge was not used this time but this and other merging approaches may be considered in the future and a new bug should be filed if it is the case.