Bug 8649

Summary: Script to assemble patches for autobuilder testing
Product: [Yocto Project Subprojects] Patchwork/Patchtest Reporter: Paul Eggleton <bluelightning>
Component: PatchtestAssignee: Leonardo Sandoval Gonzalez <leonardo.sandoval.gonzalez>
Status: RESOLVED FIXED QA Contact: Jose Lamego <jose.a.lamego>
Severity: enhancement    
Priority: High CC: benjamin.esquivel, leonardo.sandoval.gonzalez, mhalstead, richard.purdie, sgw
Version: unspecified   
Target Milestone: 2.2 M3   
Hardware: All   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Don't know
Bug Depends on: 8648, 9130    
Bug Blocks: 8714, 8716    

Description Paul Eggleton 2015-11-05 10:34:41 UTC
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.
Comment 1 Paul Eggleton 2015-11-06 10:52:01 UTC
Damien has pointed me to https://github.com/mhagger/git-imerge which may (or may not) be helpful for this.
Comment 2 Paul Eggleton 2015-11-23 21:35:17 UTC
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.
Comment 3 Leonardo Sandoval Gonzalez 2015-12-10 17:51:01 UTC
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.
Comment 4 Leonardo Sandoval Gonzalez 2016-01-28 15:18:33 UTC
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
Comment 5 Leonardo Sandoval Gonzalez 2016-02-22 23:32:42 UTC
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%
Comment 6 Benjamin Esquivel 2016-03-31 18:27:18 UTC
(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.
Comment 7 Leonardo Sandoval Gonzalez 2016-04-08 17:38:53 UTC
Michael, another bug that once the PW instance is ready, you can assign it back to me.
Comment 8 Michael Halstead 2016-05-11 21:05:16 UTC
Blocked on Patchwork upgrade.
Comment 9 Leonardo Sandoval Gonzalez 2016-06-28 15:37:24 UTC
Now that new pw instance is up, I need to test it with latest patchtest/patchtest-oe tools.
Comment 10 Leonardo Sandoval Gonzalez 2016-07-06 14:11:56 UTC
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.
Comment 11 Leonardo Sandoval Gonzalez 2016-07-12 15:32:44 UTC
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.
Comment 12 Leonardo Sandoval Gonzalez 2016-08-31 14:05:47 UTC
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.