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
That can be either a really deep change (like gcc + last package fixes to be on 100% green
but it could be also a step were only leaf packages or packages which should have less
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
like a "LATER" functionality for requests then, if something is general okay,
but not for this step.
SUSE Linux Products GmbH
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org