On Thu, 28 Nov 2013 16:46:35 +0100 Adrian Schröter <adrian@suse.de> wrote:
Am Donnerstag, 28. November 2013, 16:31:38 schrieb Josef Reidinger:
On Thu, 28 Nov 2013 16:22:41 +0100 Adrian Schröter <adrian@suse.de> wrote:
Am Donnerstag, 28. November 2013, 16:16:32 schrieb Stephan Kulow:
On 28.11.2013 16:01, Tomáš Chvátal wrote:
One of the options on the table was "lets force staging projects on everything" but sadly that is too much on the OBS and we would just be boiling it with all the rebuilds. In the end we go with above way which is technically possible and we can learn and improve it on the way wrt detecting culprits.
Basically Review team will have update SR reviewing tools with possibility to group, review, and mark for qa/staging on any submission with some possibility to edit the severity/f**kupablity of the package so they can do the right decision.
But even tho I am now interested for sure to talk about it, lets wait till we
As I said: we have to talk to the OBS team about possible solutions for the "too much on the OBS" problem. Perhaps our assumption is wrong and we can do indeed what Josef suggests: create a staging project for every submission. Then the whole discussion on who reviews and decides what will be wasted time.
we can try at least. At least as long we do not publish it and our priority handling ensures that they do not block all other people from using OBS.
I think that only tricky part of my suggestion is COW, because now if I create new repo with copy of another one everything is rebuilded, but I want just copy what is there and modify only one package, that can possible trigger another build, but not whole 6k packages rebuild if not needed.
we have the trigger="localdep" setting. Means OBS will only rebuild packages which depend on that one.
However, on the long run, this only tells if something compiles. It does not say if it works actually. So, with splitting it up, we do also need a way better automated QA since no one will be able to test all the staging projects anymore.
That is reason why I have in my proposal using openQA. Of course we can have more sets of tests and run only subset if any package affecting it changed. I hope that in future we can more focus on automatic testing of results, then on manual review of source code changes. <corporate>Because results matter</corporate> :) I think that even simply try that start software and verify basic behavior can prevent us a bunch of packaging and integration problems. Of course it cannot detect advanced problems, but I think it is not goal of factory. Josef -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org