Merge lp://staging/~chad.smith/lp2kanban/multitask-multibranch-bugs into lp://staging/lp2kanban
| Status: | Merged |
|---|---|
| Approved by: | Chad Smith |
| Approved revision: | 140 |
| Merged at revision: | 135 |
| Proposed branch: | lp://staging/~chad.smith/lp2kanban/multitask-multibranch-bugs |
| Merge into: | lp://staging/lp2kanban |
| Diff against target: |
184 lines (+51/-38) 3 files modified
Makefile (+8/-5) src/lp2kanban/bugs2cards.py (+12/-9) src/lp2kanban/tests/test_bugs2cards.py (+31/-24) |
| To merge this branch: | bzr merge lp://staging/~chad.smith/lp2kanban/multitask-multibranch-bugs |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Adam Collard (community) | Approve | ||
| Benji York (community) | Approve | ||
|
Review via email:
|
|||
Commit message
(Multi-branch bugs) bugs which have multiple branches linked to them in LP will only be considered DONE if all linked branches are approved or merged.
Multi-task bugs: only take bug status of primary project task. Ignore bug task status of non-primary tasks (series releases) unless those tasks are owned by our team in projects which we don't manage. Example: MAAS bugs with a sub task owned by a landscaper.
Description of the change
Change the behavior of lp2kanban regarding multi-branch bugs and multi-task bugs.
(Multi-branch bugs) bugs which have multiple branches linked to them in LP.
- bug is now considered DONE only if all linked branches are approved or merged
- If any linked branch or MP is Work in progress, review, or rejected the LKK card will remain in CODING state and the external branch link for the card will be set to the branch of highest rank (closest to completion, like 'In review' status).
(Multi-task bugs) Bugs which have multiple targets defined, such as landscape/trunk versus landscape/16.03 (example lp:1566923)
- lp2kanban now ignores status of the non-project bug tasks (like landscape/16.03) for bugs in projects that our board tracks. The bug card status will reflect only the "main" project task status
- lp2kanban will continue to track sub task status for our board's engineers on projects not tracked by our board
This is best explained with a some of examples:
Bug 111: two branches linked in LP
linked-branch-1: Merged
linked-branch-2: Ready for review
Bug 222: two tasks for trunk and a milestone release 16.03
task1: targets (trunk): Fix Committed
task2: targets (16.03): In progress
MAAS Bug 333: two tasks one for primary task against maas but a second task set for Landscape
task1: targets (maas): Fix Committed
task2: targets (landscape:owner Adam): In progress
-- Current LKK --
- bug card #111 is moved to Ready for QA::TODO lane because linked-branch-1 is in FINAL_STATUS Merged
- Bug card #222 is moved to $squad::Doing because one of the tasks has an 'in progress' status which is ranked lower than Fix Committed
Bug card #333 is moved to $squad::Doing because a task in another project has one of our board members on it, so we collect the status from that specific sub task
-- LKK after this branch --
- bug card #111 is moved to $squad::Review because one of the linked branches is in progress at the reviewing status
- bug card #222 is moved to Fix Committed because the main landscape project target is Fix Committed and non-project task status is ignored
- bug card #333: same behavior as #333 above
To test:
# Either make this project
make configs
make credentials
make
make check
./bin/py ./src/lp2kanban
# Or Hijack jenkins kanban sync job and point the Repository URL to lp:~chad.smith/lp2kanban/multitask-multibranch-bugs instead of lp:lp2kanban
https:/
# Or stop the jenkins kanban-sync job and patch the existing checkout (which is refreshed each run anyway)
ssh <email address hidden>; sudo -u jenkins bash; cd /var/lib/
| Chad Smith (chad.smith) wrote | # |
| Chad Smith (chad.smith) wrote | # |
| Chad Smith (chad.smith) | # |
This branch looks good. It took me a little thinking to understand the intended behavior when there are multiple branches, but once I understood it, it seems like a good way to handle things.
The container I was testing in didn't have a dependency which caused an obscure error, so I propose changing the Makefile a bit to check for the dependency.
The "tags" target doesn't work either, so I propose changing it.
There were also some PHONY targets not listed as such.
Here is the diff: https:/