Merge lp:~bjornt/lp2kanban/bugs-to-cards into lp:~launchpad/lp2kanban/trunk
| Status: | Merged |
|---|---|
| Approved by: | Graham Binns on 2012-12-10 |
| Approved revision: | 71 |
| Merged at revision: | 59 |
| Proposed branch: | lp:~bjornt/lp2kanban/bugs-to-cards |
| Merge into: | lp:~launchpad/lp2kanban/trunk |
| Diff against target: |
167 lines (+106/-1) 3 files modified
examples/config.ini (+11/-0) src/lp2kanban/bugs2cards.py (+43/-0) src/lp2kanban/tests/test_bugs2cards.py (+52/-1) |
| To merge this branch: | bzr merge lp:~bjornt/lp2kanban/bugs-to-cards |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Benji York (community) | code | 2012-11-23 | Approve on 2012-11-28 |
|
Review via email:
|
|||
Description of the Change
Support creating new cards from Launchpad bugs.
The workflow is:
1) Tag the bug you want to create a card for with the
configured tag.
2) bugs2cards.py gets all bugs with the configured tag
and creates new cards from them, if there aren't already
a card linking to that bug.
3) bugs2cards.py removes the configured tag from the bug, in
order to make the next runs faster.
I'm not completely happy with 3), since it adds noise to the bug and
requires authenticated use of the API, but it's needed, since otherwise
the list of bugs to process would just grow and grow.
I'm also not too happy of the name of the config options, but I couldn't
come up with anything better. I'm open to suggestions.
Something that I would like to do in the future is to have the type of the
card be determined by what tags the bug has, but for now it always creates
card of the same type.
| Gary Poster (gary) wrote : | # |
- 70. By Björn Tillenius on 2012-11-28
-
Pass in the project, not the project group.
| Benji York (benji) wrote : | # |
The branch looks good. I didn't see anything that should prevent this
from landing but I had several comments/
code.
> I'm not completely happy with 3), since it adds noise to the bug and
> requires authenticated use of the API, but it's needed, since
> otherwise the list of bugs to process would just grow and grow.
An idea how to tag cards as synced with kanban without having to remove
the tags later: Tag bugs that should be synced, the script then queries
for non-closed, tagged bugs and compares against existing cards,
creating those that do not yet exist.
We will be processing a few more bugs than is strictly necessary, but
once a bug is closed it will fall out of the set of bugs being
inspected, so the number of bugs examined will be bounded.
This approach also means that "semantic" tags can be used to manage
cards. For example, if you have a project to implement the "gizmo"
feature and all the "gizmo" bugs are already tagged, you can just start
running lp2kanban with the new tag name and all the bugs will have cards
created and the tags won't be removed (as they would now).
What do you think about that?
Config option brainstorming
-------
bug_new_card_tag:
- card_creation_
- new_card_bug_tag
- bug_to_card_tag
bug_new_card_type:
- bug_to_card_type
I like the last two suggestions in each category because they share a
prefix and "bug_to_card" is relatively obvious in meaning.
Is my reading correct in that create_new_cards creates all the bugs in
the left-most lane? It would be nice for that to be configurable, many
boards aren't structured that way. In fact, I can see people running
multiple passes; creating cards from one tag in one lane and cards from
another tag in another.
Hmm, maybe that doesn't matter because the cards are then synced after
they are created, thus moving them into the correct lanes. If that is
correct, then a comment to that effect in create_new_cards would be
helpful.
Shouldn't the newly created cards have the "Synced with Launchpad"
marker added to the description? Wait, since the cards are "dirty",
that will be done by save_board, right?
The tests are appreciated.
We could use some tests for create_new_cards too. I would include tests
for the lane lookup code (possibly breaking it out into its own
function) and for the card type name to card type ID translation
function (it would probably benefit from being its own function too).
| Björn Tillenius (bjornt) wrote : | # |
On Wed, Nov 28, 2012 at 02:39:57PM -0000, Benji York wrote:
> Review: Approve code
>
> The branch looks good. I didn't see anything that should prevent this
> from landing but I had several comments/
> code.
>
> > I'm not completely happy with 3), since it adds noise to the bug and
> > requires authenticated use of the API, but it's needed, since
> > otherwise the list of bugs to process would just grow and grow.
>
> An idea how to tag cards as synced with kanban without having to remove
> the tags later: Tag bugs that should be synced, the script then queries
> for non-closed, tagged bugs and compares against existing cards,
> creating those that do not yet exist.
>
> We will be processing a few more bugs than is strictly necessary, but
> once a bug is closed it will fall out of the set of bugs being
> inspected, so the number of bugs examined will be bounded.
>
> This approach also means that "semantic" tags can be used to manage
> cards. For example, if you have a project to implement the "gizmo"
> feature and all the "gizmo" bugs are already tagged, you can just start
> running lp2kanban with the new tag name and all the bugs will have cards
> created and the tags won't be removed (as they would now).
>
> What do you think about that?
Hmm. Maybe. I'm going to try it and do some timings. I currently run the
sync script to create new bugs once every minute, and would like to keep
doing so.
It also raises the question, how to delete cards from the board.
Although, I guess I could make it a config option whether to remove the
tag...
> Config option brainstorming
> -------
>
> bug_new_card_tag:
>
> - card_creation_
> - new_card_bug_tag
> - bug_to_card_tag
>
> bug_new_card_type:
>
> - bug_to_card_type
>
>
> I like the last two suggestions in each category because they share a
> prefix and "bug_to_card" is relatively obvious in meaning.
Yeah, those are good suggestion. Let's see, I will postpone merging this
branch a while, to see whether I have time to implement some other
features I want. One would be to have a default card type for new bugs,
but then being able to map specific tags to specific types. For example,
the default could be 'Feature', but if a bug is marked with a 'defect'
tag, the card type will be 'Bug'.
> Is my reading correct in that create_new_cards creates all the bugs in
> the left-most lane? It would be nice for that to be configurable, many
> boards aren't structured that way. In fact, I can see people running
> multiple passes; creating cards from one tag in one lane and cards from
> another tag in another.
Ah, that is correct, that's something I forgot to address before
proposing the merge. I'll ponder on how to do that in a nice way.
> Hmm, maybe that doesn't matter because the cards are then synced after
> they are created, thus moving them into the correct lanes. If that is
> correct, then a comment to that effect in create_new_cards would be
> helpful.
No, I don't think that will work. As far I as can see, the logic for
moving lanes are highly specific to a certain board layout, and it will
move cards only within the same horizontal lane...
| Gary Poster (gary) wrote : | # |
FWIW, I encourage landing something soon and making a separate branch for as many of the new features as you think you can postpone reasonably. There is some more work coming soon on lp2kanban AIUI from Graham's team.
- 71. By Björn Tillenius on 2012-12-07
-
Rename config options.
| Björn Tillenius (bjornt) wrote : | # |
Ok, let's get this branch landed then?
I've renamed the config options, since that's easy to do.
I will soon propose a branch that enables card moves to work for Landscape's
board layout, and after that I will add another branch for choosing which
lane to create new cards in.
I will also add more tests in later branches as well.
I don't have permission to commit to lp:lp2kanban, so please someone either
land the branch for me, or give me permission.

Hi. This sounds nice. I agree that #3 is not ideal but I can't think of another approach yet. I've asked someone in yellow squad to give you a review soon. I'd love to have this landed.
Thank you!
Gary