Am Donnerstag, 14. Juni 2012, 20:14:05 schrieb Marcus Meissner:
On Thu, Jun 14, 2012 at 07:59:07PM +0200, Adrian Schröter wrote:
Am Donnerstag, 14. Juni 2012, 17:18:45 schrieb Stephan Kulow:
On 14.06.2012 17:13, Adrian Schröter wrote:
But you could remove such packages in :Staging easily, so original Factory package would be active again. The packager can fix it in his devel project and submit it again to :Staging.
So you would basically establish an automatic revert policy via that.
The advantage of having just one :Staging instead of multiple ones would be that all eyes would be at the same spot.
OK, sounds possible. How would a time line of a gcc update or an automake update look like in your case? Please consider we have ~4000 SRs a month.
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.
The point being is that this still needs manual integration work.
This is what is missing I think, not technological work.
I think both is needed. We need a clear and better understandable workflow and mechanisms, so multiple people are able to work on the integration in parallel IMHO. What I absolute like about coolos pre staging ideas (not matter how they will be done) is that we may get a distribution where not all packages are on latest version. But better an older working one then a current broken one. And may could even prove that it was not ready (no matter if it is an upstream issue or integration issue). -- 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