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)

enhancement

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.
Priority: -- → P3
Whiteboard: [lang=python]
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → MOVED
Product: Release Engineering → Release Engineering Graveyard
You need to log in before you can comment on or make changes to this bug.