| Summary: | patchwork: provide means of recording additional patch statuses | ||
|---|---|---|---|
| Product: | [Yocto Project Subprojects] Patchwork/Patchtest | Reporter: | Paul Eggleton <bluelightning> |
| Component: | Patchwork | Assignee: | Leonardo Sandoval Gonzalez <leonardo.sandoval.gonzalez> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | High | CC: | belen.barros.pena, benjamin.esquivel, damien.lespiau, jose.a.lamego, jose.perez.carranza, mhalstead, richard.purdie |
| Version: | unspecified | ||
| Target Milestone: | 2.2 M1 | ||
| Hardware: | All | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
| Bug Depends on: | 9130 | ||
| Bug Blocks: | 8648 | ||
|
Description
Paul Eggleton
2015-04-24 10:10:51 UTC
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. *** Bug 8441 has been marked as a duplicate of this bug. *** 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. 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 It would be good to try to target this for 2.1, for completeness of bug 8648. 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. 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 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. 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. 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? > 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.
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. Waiting on Patchwork upgrade. We've upgraded to the new version of patchwork so have this functionality now. Reassigning to Leo for testing if needed. |