Manually retried builds scored to 0 priority and stay there
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
Medium
|
Julian Edwards |
Bug Description
Manually retried builds are scored behind regular uploads of any kind. They should be scored as they would for any upload of their catagory.
I have seen people do sourceful upload to fix a single architecture in order to get around this problem. This causes other buildd's to be unnecessarily burdened. Alternatively, people have to seek out a buildd admin to get builds manually rescored and this diverts them from other important work.
If there is any bias applied to a retry, it ought to come at a higher priority rather than lower since a developer has made a determination that they want that specific build done. I don't think there should be a bias, but if there is one, the current one goes in the wrong direction.
Changed in soyuz: | |
assignee: | nobody → julian-edwards |
importance: | Undecided → Medium |
milestone: | none → 2.2.3 |
status: | New → Triaged |
Changed in soyuz: | |
status: | Fix Committed → Fix Released |
Scott,
The problem with allowing retrying with the original score it that we have no way to identify if the build will succeed or fail again.
Since all uploaders are allowed to retry their failures, we can't guarantee that everyone will be as conscious as you are and will not retry obvious FTBFS several times consuming build-power for nothing.
Scheduling retried build for later gives more fairness to the system granting building slots for sources that were not tried before.
Surely for the case you pointed where you do know that the failure causes are gone and retrying the source immediately is beneficial, poking a buildd-admin isn't necessarily disrupting.