1470262 - Undo and redo bug change from 1419879 without updating timestamps

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: Administration, task, P1)

Description

[Kris Maglione [:kmag]]

Bug 1419879 bumped the change times of all bugs in the WebExtension components that it affected. This makes it much more difficult to triage bugs, since we don't know how recently active they are.

Is it possible to revert the change timestamps to their previous values before the mass change?

Comment 1

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Were these bugs moved by a script or a mass change?

Comment 2

[David Lawrence [:dkl]]

(In reply to Emma Humphries, Bugmaster ☕️ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #1)
> Were these bugs moved by a script or a mass change?

They were moved using the scripts/movecomponent.pl script that we always use for this type of operations. We have been using that script for a long time. 

We update the last changed timestamp as well as the last diffed timestamp (so emails are not sent) and have always done this. Since the change from one product to another is done to look like it was done by a human, then the timestamps have to be updated to remain consistent.

If triagers are relying on the last changed timestamp then maybe we can figure out a more fool-proof way of doing this as I would not rely entirely on that timestamp.

dkl

Comment 3

[David Durst [:ddurst]]

I don't know if it needs to be fool-proof so much as intention-proof. In this case, the intention is less about moving from one product to another and more about changing the product because a new one has been created; that's a re-categorization rather than state change that an end-user should need to know about.

I don't know where that perl script is, but that's an easy enough change (in theory).

So is the verdict that we can't change these back? Because if that's the case we either need to re-triage everything or revert this change and redo it with that intention reflected.

Comment 4

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

It'd be useful to understand how y'all are triaging bugs in WebExtensions. 

What query are you using to identify bugs to triage? 

How many bugs will you need to triage again?

Comment 5

[David Durst [:ddurst]]

We triage every week (though we did not do so last week because allhands), and the queries we're using are (aside from the obvious product and component constraints) are based on this core:

keywords=intermittent-failure, meta
keywords_type=nowords
status_whiteboard_type=notregexp
chfield=[Bug creation]
chfieldfrom=-21d
status_whiteboard=[design-decision-needed]
priority=--
chfieldto=-3d
query_format=advanced
bug_status=UNCONFIRMED
bug_status=NEW
bug_status=ASSIGNED
bug_status=REOPENED

How many will we need to triage again? Upwards of 90.

Comment 6

[Kris Maglione [:kmag]]

Our normal triage process is to go through untriaged bugs once a week, and to high priority/security bugs without assignees or progress.

But we also occasionally have ad-hoc triages, to make sure nothing is slipping through the cracks. And of course we need to occasionally read through fixed bugs to create release notes/activity reports. Having accurate change stamps makes that process much easier.

The intention of bug 1419879 was to move some components to make things easier to organize. That had the unfortunate side-effect of requiring us to change the product of all bugs in those components. But as far as those bugs are concerned, that was not a meaningful change. They're still in the same components, but the components have moved.

Comment 7

[David Lawrence [:dkl]]

(In reply to Kris Maglione [:kmag] from comment #6)
> Our normal triage process is to go through untriaged bugs once a week, and
> to high priority/security bugs without assignees or progress.
> 
> But we also occasionally have ad-hoc triages, to make sure nothing is
> slipping through the cracks. And of course we need to occasionally read
> through fixed bugs to create release notes/activity reports. Having accurate
> change stamps makes that process much easier.
> 
> The intention of bug 1419879 was to move some components to make things
> easier to organize. That had the unfortunate side-effect of requiring us to
> change the product of all bugs in those components. But as far as those bugs
> are concerned, that was not a meaningful change. They're still in the same
> components, but the components have moved.

Luckily these reorgs happen very rarely and they have always been disruptive in the past for other reasons.
From a Bugzilla technical standpoint, moving a bug from one product to another is just like any other bug
change and has to be recorded in the history table. And if we have a history entry that is newer than the
last changed timestamp on the bugs table, it can cause unseen issues elsewhere. So they must be either the 
same or the history table must be less than. Adding comments and/or attachments can also cause the last
changed timestamp to increment. 

In a perfect world, we would have a triage dashboard built into Bugzilla that can access the DB data directly
and can filter out any changes made by our script ([e-mail]) and create an effective last changed 
timestamp based on the history table highest timestamp and the comments table highest timestamp. But I do not
think the same type of query can be done through the REST API so it might have to be custom SQL directly to
the DB.

dkl

Comment 8

[David Durst [:ddurst]]

> Luckily these reorgs happen very rarely and they have always been disruptive
> in the past for other reasons.
...
> But I do not
> think the same type of query can be done through the REST API so it might
> have to be custom SQL directly to the DB.

We seem to be getting lost in a tangent here. Neither Kris nor myself is advocating for a fundamental change to BMO or some modification of timestamps. Rather, we're saying that making this kind of change (which is not as generic as moving from one product to another), which admittedly happens very rarely and have a tendency to be disruptive, should be treated differently.

From an operational POV, I would not expect that this kind of change be done via the REST API, but rather directly to the DB in the first place.

So in case this bug is mired in the phrasing of the summary, I've changed it.

Comment 9

[David Lawrence [:dkl]]

(In reply to David Durst [:ddurst] from comment #8)
> We seem to be getting lost in a tangent here. Neither Kris nor myself is
> advocating for a fundamental change to BMO or some modification of
> timestamps. Rather, we're saying that making this kind of change (which is
> not as generic as moving from one product to another), which admittedly
> happens very rarely and have a tendency to be disruptive, should be treated
> differently.

People can change the product of a bug from the UI and it is entered into the 
history of the bug same as changing the status for example. The script tries hard
to follow the same path as if someone did it through the UI. Except we do the
timestamp changes so that an extra email is not generated spamming people inboxes.
I am saying it would not be possible for use to make a bug attribute change such
as changing it's product without updating the timestamp showing when the bug was
last modified.

> From an operational POV, I would not expect that this kind of change be done
> via the REST API, but rather directly to the DB in the first place.

To be clear, I meant to be able to use the REST API to query for bugs that have
changed since a last date based entirely on the last comment timestamp and/or 
last activity entry that was not made by the [e-mail] user. Using SQL
directly would be much simpler but would require creating a simple page that would
display the results to a user dynamically.

dkl