cubicweb-vcreview #4285289 better support for multiple patches for a ticket [open]
Proposed behavior:
| |
| priority | normal |
|---|---|
| type | enhancement |
| done in | <not specified> |
| load left | 0.250 |
| closed by | <not specified> |
Proposed behavior:
| |
| priority | normal |
|---|---|
| type | enhancement |
| done in | <not specified> |
| load left | 0.250 |
| closed by | <not specified> |
Comments
-
2014/09/04 09:27, written by jcristau
-
2014/09/04 12:33, written by ddouard
-
2014/09/04 12:34, written by ddouard
-
2014/09/04 12:40, written by ddouard
add commentWhat problem does this try to solve? in particular I'm wary of the second item because not all patches may be pushed at the same time.
Indeed there's a risk of applying all the patches related to one ticket but having more patches (also related to the ticket) to come. I'm quite convinced that this situation should not occur a lot, and it's not that different from the current one; what should happen when a patche closing an already closed ticket arrives? My opinion is that, in these situations the expected behavior depends on the fact the ticket is an already published version or not.
BTW, I strongly think that with the review not being asked by default now (or soon to be), there is even less risk of not pushing these "late patches"
This would make things simpler (I think), and allow to easily play with histedit without having to edit commit messages to make sure only the top patch have the proper "closes" statement.
I think the proposed behavior is quite natural. You organise your work (by planning versions consisting in tickets, tickets implemented by applied patches). When all the elements at a given level are 'done', the container WF status should automatically be changed. It does not forbid from changing back (by hand) a given WF state is required.