Dne St 4. prosince 2013 19:58:00, Stephan Kulow napsal(a):
Am 04.12.2013 18:34, schrieb Adrian Schröter:
So as me and Michal played with this for a week or so before we got another
crazy stuff here is what we prepped.
> we could start with creating a staging project for large submissions like
> entire KDE update.
That actually is not needed as kde submission is quite self-contained. But on
the other hand the Gnome stuff often need multiple passes in repo-checker to
get in so it might not hurt to start there. :)
And then have some collection projects, where we collect everything, which
did not fit somewhere else for, let's say 2 weeks. After 2 weeks we do
the next staging project and continue to fix the former one until it
What do you think?
I think that there is a lot to fix and enhance before we can handle it
and discuss. E.g. I have no way to see if openSUSE:Factory:Staging:NoFam
already contains changes or if its pure
We worked on this in the factory-auto repo .
The verification is actually half done, we wrote staging plugin for osc and
this is mostly the only part that is done and working - checking whether
staging project contains only links without any local modifications.
What needs to be added is checking if the changes are all part of the GR# or
actually already merged in factory if it is the fact. As now the checker just
validates that all the changes are back in devel projects.
The script now can create staging (might need adjustment to be the no-publish
repo and maybe other tweaks to reduce the load) and check if it is clean (no
changes directly in there) and of course delete the staging, but without
verification for now so it can in fact wipe almost anything even if you don't
want it to.
There are also completely empty functions to push to factory, eg mark the
grouprequest as passed over staging if it is the fact.
And function to submit the stuff back to devel projects from the changes within
the staging (that one is easy to do but we didn't work there yet as it was
lower on the testing list).
IMO we basically need to find out what problems are
common to all models
and start hacking. Once we're there, we can test different scenario. The
models will only be as good as the tools to support them.
The problems we faced there were more on the tooling side which we can
overcome by writting the api where needed (which I personaly can't do even if
I try best, I wrote like 20 lines top in Ruby).
So the issues we faced:
If you create loads of stagings the wait-on-result was quite longish TM. MIght
be solved by not publishing it or creating them as "frozen" set that can be
refreshed when needed.
No way how to update the staging for now. Our plan was to use the groups in a
way where you could call update, and it would check the grouping request that
is in the staging and refresh it based on new submissions in there if needed
(could be also hook on group request that each time the GR is updated the
staging is refreshed, would be probably much better than command on the client
Addition is not written, you have to do the linkpac yourself in the repo now.
Might be better to allow it in two ways, adding directly to group request
(with osc group add) or via staging where you can do (osc staging add SR#)
which would do the same; add SR# to the staging groupID and update the
If you look on the repo there is .dot file which has "workflow" as thought us
and it is heavily dependant on the grouping requests at least how we pictured
it. So we need to adjust the groupings to be able to accept them, get properly
their state and status of all subrequests within the group.
Tom + Michal