7658 2015-04-24 10:10:51 +0000 patchwork: provide means of recording additional patch statuses 2017-12-06 16:48:38 +0000 1 1 6 Yocto Project Subprojects Patchwork/Patchtest Patchwork unspecified All Multiple RESOLVED FIXED High enhancement 2.2 M1 9130 8648 1 bluelightning leonardo.sandoval.gonzalez belen.barros.pena benjamin.esquivel damien.lespiau jose.a.lamego jose.perez.carranza mhalstead richard.purdie --- --- No (bug/feature does not impact docs) oldest_to_newest 50504 0 bluelightning 2015-04-24 10:10:51 +0000 It would be useful to provide some way to see more fine-grained status of patches - e.g. when a patch is being tested / failed testing / passed testing. 50565 1 bluelightning 2015-04-28 17:35:14 +0000 Apparently it's possible to add custom statuses, however some of these aren't mutually exclusive - e.g. it would be nice to see if a patch was tested or not independently of whether it is merged or not, therefore Damien suggests that implementing support for tags might be a better approach. 54969 2 jose.a.lamego 2015-10-05 16:09:59 +0000 *** Bug 8441 has been marked as a duplicate of this bug. *** 54970 3 jose.a.lamego 2015-10-05 16:11:57 +0000 Additionally to previous comment, it was requested to evaluate and implement if feasible,the creation of a new patchwork state as a way for tracking patches merged in master-next. Later these patches may be either merged in master or dropped, following the regular patch workflow. 55766 4 damien.lespiau 2015-10-26 16:13:58 +0000 As mentioned status and test results are two different things: a patch can be both passing one or more tests and be superseded or accepted. I tried to summarize the current state of what I'm thinking of: https://github.com/dlespiau/patchwork/issues/59 56253 5 benjamin.esquivel 2015-11-05 23:18:23 +0000 It would be good to try to target this for 2.1, for completeness of bug 8648. 56962 6 belen.barros.pena 2015-12-02 19:51:13 +0000 We need to work out what the Yocto Project patch workflow will be (which are the statuses a patch goes through and how it moves from one to the next). We should not mix patch statuses with test results (which right now I believe are submitted per series, not per patch), and we should not have patches in more than one status. 57188 7 benjamin.esquivel 2015-12-10 21:42:09 +0000 We should be able to see in M2 what the flows are going to be in the patchwork process so we can know what do we want to see as additional info 59696 8 leonardo.sandoval.gonzalez 2016-03-03 17:45:41 +0000 Moved to M4. It will resolved once 9130 is done. The new PW instance to be launched includes this feature, but at series level, good enough for the Yocto Project needs. 59698 9 damien.lespiau 2016-03-03 18:01:24 +0000 So, actually, Patchwork already supports adding new patch state. One just needs to add a row in the State table and the whole project should pick it up (so for instance, you can set the new state on patches) So I'm not sure what else is needed there. 60623 10 benjamin.esquivel 2016-03-31 18:21:58 +0000 Agreeing with Damien that the new instance solves this bug, as it is written. It would be missing a bug for _actually_ adding the states. Can this be closed when the new patchwork instance is up and running? 60754 11 leonardo.sandoval.gonzalez 2016-04-04 20:32:53 +0000 > Can this be closed when the new patchwork instance is up and running? yes. It should be closed as soon as I test this feature on the new PW instance. 60983 12 leonardo.sandoval.gonzalez 2016-04-08 17:26:16 +0000 Michael, As mentioned in the last comments, this feature is already implemented on the new patchwork instance. Once the instance is ready, please assign it to me again so I can test and resolved it. 62130 13 mhalstead 2016-05-11 21:04:17 +0000 Waiting on Patchwork upgrade. 63726 14 richard.purdie 2016-07-07 15:02:27 +0000 We've upgraded to the new version of patchwork so have this functionality now. 63800 15 mhalstead 2016-07-11 16:53:43 +0000 Reassigning to Leo for testing if needed.