display of time of removal requests is ambiguous - can be read as time for removal was time of request
Bug #242585 reported by
William Grant
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Triaged
|
Low
|
Unassigned |
Bug Description
After having vlc redemoted (to finish the saga replayed in my previous Soyuz bug), the superseded SPP declares that it has had its removal requested... tomorrow. I find it somewhat scary that it should know this.
Changed in soyuz: | |
status: | New → Confirmed |
Changed in soyuz: | |
importance: | Undecided → Medium |
status: | Confirmed → Triaged |
Changed in soyuz: | |
assignee: | Celso Providelo (cprov) → nobody |
summary: |
- Domination procedure jumps into the future to request removal + removal requests show time to be removed as time of request |
summary: |
- removal requests show time to be removed as time of request + display of time of removal requests is ambiguous - can be read as time + for removal was time of request |
Changed in launchpad: | |
importance: | Medium → Low |
To post a comment you must log in.
Willian, this is normal, the publication in universe 'dominated' the one in multiverse, since it had no binaries at that moment it it could already be removed from disk after waiting 24 hours (stay-of-execution time used for the ubuntu PRIMARY archive).
The death-row code will realize it's not really a removal but yet a move when it's time.