Information on when a bug was closed

[edin-ogtal]

Hi @sanacl and @alpgarcia I am currently working with the bugzilla index. I would like to determine how much time passed between the creation of a bug and the time a bug is "closed" (changed state to Resolved, Verified etc.).

I initially assumed that the "timeopen_days" field contained this information, but this doesn't seem to be the case.

Is there any straight forward way to determine how long a bug was open for?

[hmitsch]

Hi @edin-ogtal,

the question you ask for is probably answered in the Kibabana UI: https://sotrar.mozilla.community/app/kibana#/dashboard/Bugzilla-Timing

Are you aware of this? Not sure if this is helpful. Sorry if I missed the point in your question.

Best regards, Henrik

[alpgarcia]

Looking at the data it seems you are right, that field is not correctly calculated for closed issues. Looking at the code it seems I'll open a bug about this [1].

You could use time_to_last_update_days that stores the bugzilla field last_change_time or directly calculate the time using changeddate_date and grimoire_creation_date: https://sotrar.mozilla.community/goto/2a1caad51df205718e67454abdaf9758

Of course you need to filter in closed bugs only. It may happen that some bug could have some activity after being closed. I'd say that is not the usual pattern, but don't have any numbers to confirm this.

For having more precise info you'd need to rely on the RAW index (see https://github.com/mozilla/participation-metrics-org/issues/193#issuecomment-476846238). Unfortunately we don't propagate the field cf_last_resolved, that should be at the top level of the data object too (no need to dive in the history of events as in the comment referenced above).

GET bugzilla-raw/_search?q=data.resolution:"FIXED"

...
        "_source": {
          "backend_name": "BugzillaREST",
          "origin": "https://bugzilla.mozilla.org",
          "uuid": "a786dd92ee7574ccc65fad7a8b383845dd07b4d0",
          "ocean-unique-id": "1339571_https://bugzilla.mozilla.org",
          "metadata__timestamp": "2017-02-15T03:50:03.120651+00:00",
          "timestamp": 1487130603.120651,
          "updated_on": 1487119504,
          "metadata__updated_on": "2017-02-15T00:45:04+00:00",
          "perceval_version": "0.4.2.dev0",
          "tag": "https://bugzilla.mozilla.org",
          "backend_version": "0.5.0",
          "category": "bug",
          "data": {
            "attachments": [],
            "cf_qa_whiteboard": "",

            "resolution": "FIXED",    <---------

            "product": "Infrastructure & Operations",
            "assigned_to_detail": {
              "name": "infra@infra-ops.bugs",
              "id": 472678,
              "email": "infra@infra-ops.bugs",
              "real_name": ""
            },
            "summary": "AUK - Videomonitoring1 - not working",
            "classification": "Other",
            "cc": [
              "bhourigan@mozilla.com",
              "lgray@mozilla.com"
            ],
            "target_milestone": "---",
            "creator_detail": {
              "name": "thenderson@mozilla.com",
              "id": 581995,
              "email": "thenderson@mozilla.com",
              "real_name": "Tyler Henderson"
            },

            "cf_last_resolved": "2017-02-15T00:45:04Z",  <-------

            "creator": "thenderson@mozilla.com",

            "is_open": false,   <------ this one may be interesting too

...

cf_last_resolved is a custom field, that's why we don't have it in the enriched index. As long as you are using only Mozilla's data, you can rely on it to compute the time you need.

Best, Alberto.

[1] https://github.com/chaoss/grimoirelab-elk/blob/master/grimoire_elk/enriched/bugzillarest.py#L121

[alpgarcia]

FYI, bug reported: https://github.com/chaoss/grimoirelab-elk/issues/602

[edin-ogtal]

@hmitsch and @alpgarcia Thanks for the quick reply. I'll give it a try with time_to_last_update_days - the method you describe should work for ~70 % of all bugs.

[havardl]

Might be ready next week according to this: https://github.com/mozilla/participation-metrics-org/issues/205#issuecomment-482405677

For now, we continue working with @edin-ogtal workaround.

[canasdiaz]

Hi @havardl, we have the software ready to generate a new index for bugzilla to allow you to identify when the bug was closed. According to last time we did it, it will need 1 or 2 nights (taking into account the software only runs from 6PM to 6AM CEST).

So, it is totally up to you. Do you want us to generate the index or you are ok with the workaround you are using?

CC @havardl @edin-ogtal

[havardl]

Hey @sanacl, thanks for following up on this. It would be great if you could re-generate the index. Also, we are currently not working on the instance, so you can run it for 24/7 to speed up things.

[canasdiaz]

Hi @havardl @edin-ogtal , we have the new enriched index for bugzilla (index alias bugzilla, index name bugzillarest_mozilla_180411_enriched_190507).

Some comments about the data:

• we are using the raw index (latest one was updated on March 18th), it means if a bug was closed on March 20th it is still open in this data set (in this index I mean)
• the new enriched index contains a field named timeopen_days but you have to modify it carefully. For the bugs still opened by March 18th it is calculated between the creation time and yesterday. Remember, raw data is not updated since March 18th. So if we want to emulate the data calculated on March 18th we would need to subtract 50.16 days to all the tickets with the state NEW.
• the field time_to_last_update_days contains the diff between the creation and the last activity. For bugs with no activity after the creation the value is 0. It is calculated subtracting creation_ts - delta_ts

Let us know whether the information is clear and you need us to help you anyhow.

[canasdiaz]

Hi all, I'm moving this to Done and closing. If you miss anything please re-open and mention us.

CC @edin-ogtal @havardl @hmitsch