9942 2016-07-14 15:16:42 +0000 patchwork: ensure patches are not marked as Accepted when a newer Series revision is modified 2017-12-06 17:03:13 +0000 1 1 6 Yocto Project Subprojects Patchwork/Patchtest Patchwork unspecified All Multiple RESOLVED FIXED Medium+ normal 2.3 M1 10153 1 jose.a.lamego jose.a.lamego bluelightning leonardo.sandoval.gonzalez sgw --- --- No (bug/feature does not impact docs) oldest_to_newest 63987 0 jose.a.lamego 2016-07-14 15:16:42 +0000 Patches from a previous revision (v1) were marked as Accepted after two patches in a newer series revision (v2) were changed to Accepted state: https://patchwork.openembedded.org/series/271/ Wrongly marked patches: 126549, 126551, 126553, 126555, 126557, 126559. Find root cause and verify that there are no other affected series. 65540 1 jose.a.lamego 2016-08-25 21:57:35 +0000 Attempted to replicate the issue at a staging instance with the following conditions: - Same Patchwork commit as in OE-Patchwork (fc3c66a1ac3e94ce26ca29b4296f1196b869cbac) - Created an initial patch Series from patch email messages created with create-pull-request script - Created both a subsequent (v2) patch Series and a second revision (for original series) from patch email messages created with create-pull-request script - Updated some patches from second revision/series But reported behavior was not detected. This seems to be a symptom and result of a bad series creation, which is fixed in bug 9904. After this fix is implemented, further testing will support this assumption. 65938 2 leonardo.sandoval.gonzalez 2016-09-08 17:07:59 +0000 This wont be ready for M3 due to the dependency (not met). Moving to M4. 67356 3 leonardo.sandoval.gonzalez 2016-10-19 13:54:29 +0000 This bug is still depending on 10153 but I believe we can move both to 2.3 M1. 10153 is launching a PW testing instance so this is definitely something can be done post 2.2. 68990 4 jose.a.lamego 2016-12-09 17:07:49 +0000 Couldn't replicate issue at patchwork-staging instance with series 3895 [1], adding to the assumption that the reported issue was caused by a wrongly-created series, which is already fixed in production. [1] https://patchwork-staging.openembedded.org/series/3895/