Project

General

Profile

Actions

action #1795

closed

request finder should ignore declines

Added by coolo about 10 years ago. Updated about 10 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Start date:
2014-03-05
Due date:
% Done:

90%

Estimated time:

Description

There are 2 bugs in request finder both shown with this "screenshot":

coolo@gertrude#STABLE>osc staging select D moarvm nqp rakudo
There are multiple requests for package "nqp": 224648, 224609, 224649

There are indeed 2 requests for nqp that could be potentionally meant:



But I can't imagine a use case where I want to group a declined request when there is a
another request in review,new. There are use cases when I mean the declined request for a package
if there is only one.

And the other bug in request finder is in the error handling. The first request in the
list of "multiple for nqp" is actually for moarwm. But the requests output are all currently collected.

Actions #1

Updated by coolo about 10 years ago

  • Status changed from New to In Progress
  • Assignee set to coolo
  • Target version set to Staging sprint 3

working on it

Actions #2

Updated by aplanas about 10 years ago

Redefine the is_declined:

  • RequestFinder (for package names and for project) need to find the last request ID for every package
  • RequestFinder (for ID) will detect if the package the declided and is not the last or is supersede, and will abort with an error
  • is_supersede can now deduce that is a supersede if find a request ID in a staging project with ID < new_id
Actions #3

Updated by scarabeus_iv about 10 years ago

  • Target version deleted (Staging sprint 3)
Actions #4

Updated by scarabeus_iv about 10 years ago

  • Target version set to Staging sprint 4
Actions #5

Updated by aplanas about 10 years ago

  • Assignee changed from coolo to aplanas
Actions #6

Updated by aplanas about 10 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 90

I am not sure that the use case if 100% covered but I think so:

  • The trunk of the fix was made by coolo when the takes care of request id that are in declined state
  • I added some asserts and condition that constrain the definition of a supersede case

I will close the bug, but there are chances that a new use case appears that invalidate the fix

Actions

Also available in: Atom PDF