Proposal: Staging State for Requests

[coolo]

I have a proposal to untangle the discussion with backlogs and staging managers and such.

I think what we need is an explicit state of the request within the workflow. The default state is 'incoming' (to avoid 'new' not to be confused with request states)

Then it can either be ignored (which might or might not be implicit) or it can be selected. As the selection process is async, I would make this an extra state.

mermaid doesn't really render this nicely, but this is how it looks sketched:

[vpereira]

Hi @coolo,

do you see a problem to, instead of create a new BsRequest state, do it through the new relationships between models?

[coolo]

What relationship is Selecting?

[vpereira]

What relationship is Selecting?

The staging plugin "select" command, is covered by the relationship between a bs_request and a staging_project: https://github.com/openSUSE/open-build-service/blob/staging-workflow/src/api/app/models/staging/staging_project.rb#L3

is that what you meant @coolo ?

[coolo]

this is selected - I'm talking about the state while your background job is running

[vpereira]

this is selected - I'm talking about the state while your background job is running

We will probably run it in the main thread, blocking. Therefore no background job.

[adrianschroeter]

please don't invent a new requests state for this, it would affect external api (and used osc clients would just crash). Can't you use a dirty marker instead? That fits IMHO also better to that situation and is similar what we do in other places regarding states.

[coolo]

this wasn't supposed to extend the request state - but be a staging state.

[vpereira]

this wasn't supposed to extend the request state - but be a staging state.

you mean the bs_request would have a new field, named staging_state?

[coolo]

that was a proposal, but let's keep the state implicit

[hennevogel]

I would rather talk about why you think you need an extra state and why new isn't enough. Then we can think of solutions.

[coolo]

because a request can be in 'new' all the time. If it's incoming or if it's acceptable.

[hennevogel]

So don't you want to rather have some "state" somewhere when it's mergeable?

[coolo]

Well, any mean to differ requests before and after the process - so we can drop the reviews.

[vpereira]

Well, any mean to differ requests before and after the process - so we can drop the reviews.

@coolo Reviews are used for many things in the Staging Workflow (TM). Where exactly do you want to drop the reviews? Because I first understood exactly that: you want to stop to use the review, but then I hear that we won't touch in the review based workflow.. could we write it down?

[coolo]

We can only drop the reviews if we have another mean.

Currently (in OBS terms): Incoming == review by_group staging-manager Staged == review by_project StagingProject Acceptable == new

[vpereira]

Hey @coolo

could you help me to define these terms?

Currently (in OBS terms): Incoming == review by_group staging-manager Staged == review by_project StagingProject Acceptable == new

Searching for incoming what I found was the following:

Incoming: https://build.opensuse.org/project/requests/openSUSE:Factory (all new requests with openSUSE:Factory as target). The incoming as you described, I couldn't find in the OBS. Could you please give me some pointers?

Staged: Requests with relationship with Staging Projects

Acceptable: All new requests with openSUSE:Factory as target (as the incoming described by me)?

[coolo]

Right now factory's incoming backlog is here: https://build.opensuse.org/group/show/factory-staging

[vpereira]

Right now factory's incoming backlog is here: https://build.opensuse.org/group/show/factory-staging

Backlog! Now I know what you mean. I updated already the staging workflow glossary: https://github.com/openSUSE/open-build-service/wiki/Staging-Workflow-glossary

[vpereira]

@coolo

Currently (in OBS terms):

Incoming Backlog == review by_group staging-manager Staged == review by_project StagingProject Acceptable == all new requests with target project openSUSE:Factory

In the Staging Workflow 2.0:

Incoming Backlog == review by_group staging-manager (?) Staged == StagingWorkflow#staging_projects#staged_requests Acceptable == StagingWorkflow#target_of_bs_requests#ready_to_stage

so if you help us to define a way to represent the Incoming Backlog (without new BsRequest state, without Review), via one of the many model relationships that we have, would be awesome.

What I think is missing here is the list of packages that should be staged. In the Factory process we have the Rings, but I don't see it anywhere. Then the Incoming could be created with:

StagingWorkflow#unassigned_requests (but inside of unassigned_requests we should check the list of packages needing Staging)