Closed Bug 984877 Opened 10 years ago Closed 9 years ago

Expose an AlertID

Categories

(Datazilla Graveyard :: Metrics, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: ekyle, Unassigned)

References

Details

3) Do you think it might be helpful to have an "alert ID" or something unique that we could put in a bug subject line?  This would make it easier to avoid having multiple people open bugs for the same alert. Ideally this would be conveniently added from a "Open new bug for this alert" link or something.
Thoughts on the format for the AlertID?  I believe something in the whiteboard like "[dza23498723]" might allow the DZ and the alerting app to find BZ bugs with the specific alerts.

Please suggest a format (or tracking field?) for the AlertID as seen in Bugzilla.
Flags: needinfo?(jmaher)
Flags: needinfo?(bkelly)
I like this idea in general, would a summary or whiteboard be better?  What if there is a single root cause for 10 different alerts?

I think this is probably something we will change after we implement it.

A whiteboard might be confusing, likewise a summary could be too.  It wouldn't be confusing without context- how can we add context reliably?  I think a link to a UI showing the alert and details (whether that is a custom app, treeherder, datazilla, etc.)

For the record, I have been trying to add references to alerts on dev.tree-management to bugs in the comments section- not very discoverable.

I vote for whiteboard tags for now.
Flags: needinfo?(jmaher)
After thinking about this some more I believe it may be premature.  Lets wait until we start implementing stateful features so we can design it based on what we actually need at the time.  Otherwise we're likely to get it wrong and have to rework anyway.  Just my opinion.
Flags: needinfo?(bkelly)
Ben,

I would like associate alerts with bugs now, even if only to find out what does not work.  I want to do this for both exposing an "AlertID", and for providing a "create-bug" link.

1) Is the "dza" prefix in may example too ugly? [dza23498723]
2) Should the prefix be a word? [alert23498723]
3) Do we usually use dashes? [alert-23498723]
4) Are IDs inhumane? [alert-cold-load-time-contacts-2014-04-15]

I ask these simple questions because I have never created a whiteboard tag before.  Really I am asking: "Does Mozilla have a (unspoken) whiteboard tag standard?"


Joel,

May you give me an example of what the comments references look like on dev.tree-managment?  I do not like the idea of comment references because they can not be removed (in the event a mistake is made).  But I do like the idea of comment references adding context.
Flags: needinfo?(bkelly)
(In reply to Kyle Lahnakoski [:ekyle] from comment #4)
> 1) Is the "dza" prefix in may example too ugly? [dza23498723]
> 2) Should the prefix be a word? [alert23498723]
> 3) Do we usually use dashes? [alert-23498723]
> 4) Are IDs inhumane? [alert-cold-load-time-contacts-2014-04-15]

I think I would go with something that will minimize "whats this whiteboard tag" type questions.  So I prefer "alert-1234", "alert-id-1234", etc.  At the end of the day, though, I don't have a strong opinion on format.
Flags: needinfo?(bkelly)
Here is a bug where I referenced what appeared to be the root cause in the title and it was changed upon further analysis:
https://bugzilla.mozilla.org/show_bug.cgi?id=985477

The title can be changed, maybe that is the place to put it.  Personally I like a title to read:
x% regression in <test_name> on <branch> from [bug xyz|revision abcdef]

This makes it easier to query the whiteboard [talos_regression] and see what is open/available.  Thinking more, I should put the date in there so it would be more like:
x% regression in <test_name> on <branch> from [bug xyz|revision abcdef] landed 2014-03-14

I do not think there is a standard for whiteboard tags, we have tracking programs built upon them.
dzAlerts is a dead project
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.