Closed
Bug 1392720
Opened 8 years ago
Closed 6 years ago
figure out how to make scheduled change "when" behaviour more consistent
Categories
(Release Engineering Graveyard :: Applications: Balrog (backend), enhancement, P3)
Release Engineering Graveyard
Applications: Balrog (backend)
Tracking
(Not tracked)
RESOLVED
MOVED
People
(Reporter: bhearsum, Unassigned)
Details
(Whiteboard: [lang=python])
The current behaviour of Scheduled Changes that use "when" is:
- You cannot schedule them in the past when you create or update them
- Scheduled Changes are not enacted until the "when" time has arrived _and_ the required signoffs have been met.
This means that an already scheduled change may end up being scheduled "in the past" if signoffs do not arrive in time. It's confusing and inconsistent that you can't schedule a change in the past, but it can drift there.
A couple of ideas about how to fix this:
1) Allow changes to be scheduled in the past. The original reason for this safeguard was that we didn't want them enacted immediately. Now that we use Signoffs for most channels, this generally won't happen.
2) Support a value like "immediately" or "ASAP" as a "when". Changes could be initially scheduled with this, and they would be automatically changed to this if they are not enacted prior to the original "when". This would effectively have the same behaviour as a "when" in the past, but it would be more obvious.
| Reporter | ||
Updated•8 years ago
|
Priority: -- → P3
| Reporter | ||
Updated•8 years ago
|
Whiteboard: [lang=python]
| Reporter | ||
Comment 1•6 years ago
|
||
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → MOVED
Updated•6 years ago
|
Product: Release Engineering → Release Engineering Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•