sort issues hierarchically

[vingu-linaro]

Signed-off-by: Vincent Guittot [email protected]

[jbech-linaro]

This line is wrong and gives Python errors.

[vingu-linaro]

Ah yes, a last minute changes with a wrong copy/paste to try to make comment more readable.
Will fix it

[jbech-linaro]

Could we keep all the writes here as done previously and then follow the same pattern as I did withwrite_last_jira_comment, but instead of an argument, add it as a configuration option in the yaml file? I.e, in the yaml-file:

show_parent: True

And then here (just after line 237, # Status ...) add:

    try:                                                                                      
        if g_yml_config['show_parent']:
             f.write(write_parent(jira, issue))
    except:                                                                                   
        vprint("Parent not found in config")

That means that the parent link also would need to go below the issue ID itself (and not before as in your patch), for example:

[SWG-3]
# Header: Generic TrustZone device driver for Linux kernel (upstream)
# Type: Epic
# Status: In Progress
# Parent: SWG-1
# No updates since last week.

I think that would make it a bit cleaner and will give people the option to enable/disable parent links at will. Seems like people have lots of different opinions on what should be there by default and how that should look like. In that case it it probably best to make it configurable.

[vingu-linaro]

My goal was to keep a kind of hierarchy
[parent1]
[child11]
[child12]
[parent2]
[child21]
[child22]

But when a parent (parent2) is not in the list of issues to update we have
[parent1]
[child11]
[child12]
[child21]
[child22]

Which can be a bit confusing so my goal was to add a comment when we change the parent
[parent1]
[child11]
[child12]
#[parent2]
[child21]
[child22]

Furthermore, this can be easily used to add a summary of childs activities into the parent by uncommenting the issue id

[jbech-linaro]

I see, that's a bit different to how I first understood that it was supposed to be used. I was thinking it was just going to add a parent link to each issue. Let me think a bit more about this.

[jbech-linaro]

So, I've looked into this, currently you are checking for parents and then parse issues one by one and then mark them as done etc. How about instead adding all issues to a dictionary where the key is simply the parent. By doing so you can easily sort on the key (parent) if you want to and as a inner loop you print each issue belonging to that key/parent. That would give what you are asking for, but I think it's a bit easier to implement and read. If you want I can make a patch for it.

Btw,

#[parent2]
[child21]
[child22]

How do you figure out that it should be "parent2" if there is no parent? Or are you just grabbing a name?

[jbech-linaro]

So, some more thinking about this, it can be pretty complicated. What you want to achieve I guess is:

[Initiative1]
  [Epic1]
  [Epic2]

or

[Epic1]
  [Story1]
  [Story2]

or

[Initiative1]
  [Epic1]
    [Story1]
    [Story2]
  [Epic2]
    Story3]
    [Story4]

I.e, you want to show the tree. However, there are no limitations to how many parents you can have. One Epic can implement several Initiatives, likewise a Story can implement many Epics (this is not the normal case, but it can happen). So let's say an Epic implements two Initiatives, how should that be represented in text format?

[Initiative1, Initiative2]
  [Epic1]
    [Story1]
    [Story2]

[Initiative1]
  [Epic2]
    [Story3]
    [Story4]

Take it one more level, let's say Story1 implements Epic1 and Epic2, then things are becoming pretty complicated when it comes to how to represent it :)

Just putting Stories in a group linking to a single Epic is easy, so is grouping Epics pointing to a single Initiative. But that will not cover the corner cases.

[vingu-linaro]

For now, i have not supported multi parents but it should not be that complex as the "parent" key can be an array of parents. In case of multi parent the easiest is probably to show the child in each parent so user can put its comment according to the context of the parent

[Initiative2]
[Epic1]
[Story1]
[Story2]

[Initiative1]
[Epic1]
[Story1]
[Story2]
[Epic2]
[Story3]
[Story4]

I will also update the patch to have the full path otherwise we can miss some links like:

[Initiative1]
[Epic1]
[Story1]

[Initiative2]
[Epic2]
[Story2]

#[Epic3]

parent is Initiative 1

you are not assigned to this card

[Story3]