-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ring: create command for making and recording ring changes and process during accept #848
Comments
Touch the project description if removing a package so it shows up as changed in OBS list and clears everyone's caches. |
👍 |
#897 will be useful second part to this to ensure packages added to rings in a staging remain enabled when superseded. |
BTW we have try to avoid the newdep being add to project rings in case the required package was out of that staging. Ie.
|
AS an addittion: it would be nice if I could 'link' such a new dependency to a package, sort-of as a 'reason' so: pkg FOO is newly requiring in Ring2 (staging:X:DVD) because of pkg BAR, which is submitted as request xyz (especially interesting in case BAR is removed from :X, then the ring changes would no longer apply) |
After discussion this tool would be rather useful in general and likely a precursor to #815.
There are several scenarios to support.
select --ring 2 A foo
(enabled instead of disabled)select --ring 1 A ring_2_package
(marked as moved)select A foo
(disabled and placed in letter project not DVD like current behavior)ring A 1 ring_2_package
(move package from ring 2 to 1 in staging A)ring 1 ring_2_package
(move package from ring 2 to 1 in project rings)ring 2 ring_1_package
(move package from ring 1 to 2 in project rings)ring ring_2_package
(remove package from ring 2 in project rings)ring --reset A foo
(drops metadata and reverts package to previous ring state)ring --reset A
Future
select
should utilize the recorded ring changes to override base ring placement. Thus if a package is moved from ring 2 to 1 and a request is then staged in that staging the request will be placed in ring 1.These commands can be issued from
cleanup_rings
instead of the command pairs that are currently issued.accept
will then apply the changes made in a staging to the project rings. For example:select --ring 2 A newdep
ring A 1 moving_up_in_the_world
(currently in ring 2)accept A
Would result in:
accept
behaviornewdep
added to ring 2 in project ringsmoving_up_in_the_world
moved from ring 2 to ring 1 project ringsHaving a command to print out ring changes almost like
check
or astatus
command would seem handy. For now this likely makes sense to just include inring
command.ring A
Prints recorded ring changes to staging
A
or indicates if there are none.The text was updated successfully, but these errors were encountered: