Am Donnerstag, 14. Juni 2012, 21:01:27 schrieb Adrian Schröter:
Am Donnerstag, 14. Juni 2012, 20:16:37 schrieb Stephan Kulow:
Am 14.06.2012 19:59, schrieb Adrian Schröter:
gcc is really very special, Richard is already doing test builds of entire Factory in his own project and I think this going to stay for first testing.
However, afterwards :Staging would define the next transaction to be checked into Factory.
That can be either a really deep change (like gcc + last package fixes to be on 100% green again), but it could be also a step were only leaf packages or packages which should have less impact. The later case should be faster to test since way less packages need to be build.
However, it would be up to the release manager/team to define this step. Maybe we would need something like a "LATER" functionality for requests then, if something is general okay, but not for this step.
That still is not good enough for me to understand what you mean. A transaction is what? a bunch of submit requests?
basically every package in :Staging would be submitted to Factory and :Staging would be empty again afterwards.
So devel projects would stay, but SR to :Staging and from there we copy it when what happend?
When we say :Staging is okay. No package failing, everything green. Or we say we take some packages for this transaction.
I guess what I don't understand: how is having everything in one :staging an advantage over having everything in :Factory? I can revert single broken packages right now too - once I understand where the problem comes from. The problem is how to fix the problem - if the ruby update only breaks devel:languages:ruby, but not the packages in let's say system:management - unless ruby ends up in factory.
hm, that would mean that deeper packages can only be added to :Staging alone and you need to wait until everything inside depending on it has finished.
I think you will point out now that this may take too long so you need multiple :Staging in parallel (and the build power for it).
A side note, what I do see here as well is that we may should go back to entire clean builds at least in these :Staging projects instead only the packages with source changes ...
Just to draw a picture, such transactions could be similar to what we do with maintenance updates. There could be openSUSE:Factory:Staging:<number> projects. realease managers would sort the submit requests into them. For example openSUSE:Factory:Staging:103 is just for binutils & gcc update. It is currently building all factory packages to see if it has an effect. openSUSE:Factory:Staging:104 contains random leaf packages. not much changed, but you still wait for live cd builds to see if the new packages may make them to big. openSUSE:Factory:Staging:105 got an KDE 4.99 update plus some qt packages. Build is finished, everything fine. Could be merged into openSUSE:Factory. We could even do it similar with maintenance and just move source and binaries (with re-signing), so we would avoid extra builds. It does not matter in which order these projects get merged. But after one got merged the others may need to rebuild. So we should not get too many in parallel ... -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org