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 open the next staging project and continue to fix the former one until it settles.
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 [1]. 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 side). 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 project. 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. Cheers Tom + Michal [1] https://github.com/coolo/factory-auto/blob/master/osc-staging.py