If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Allow to edit closure messages without creating another history entry

RESOLVED FIXED

Status

Release Engineering
TreeStatus
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: glandium, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
Essentially, after every global tree closures, elm is reopened widely instead of keeping its original approval required status. I don't notice quickly, and fortunately, nobody is pushing to elm other than me, but this is annoying, and I'm sure other branches are affected by this.

Could treestatus make reopening a closed tree restore the status it had before being closed *by default* instead of reopening?
As discussed on IRC, it does keep it by default, the problem is that there isn't a reasonable way to edit closure messages after the fact other than by stacking up another closure, so in the closure where you lost it (which was in February, it's hardly "every") the previous state was probably kept for the "Bug 1134797 - Jobs not being scheduled" closure, but because that was a typoed number, keeping history again as it was edited to "Bug 1134767 - Jobs not being scheduled" would have meant that reopening would require changing back to every tree closed for the invalid bug number, and then back to the previous state.
Summary: Allow to easily restore last status after closure → Allow to edit closure messages without creating another history entry
(Assignee)

Updated

2 years ago
Product: Tree Management → Release Engineering
You can now edit the tree closure message without adding a new stack entry.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
QA Contact: dustin
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.