Am Donnerstag, 14. Juni 2012, 15:32:15 schrieb Dominique Leuenberger a.k.a DimStar:
Quoting Adrian Schröter
: 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.
Surely an approach, but timing wise you'll probably get really a low throughput.
IMHO the overall throughput should not be affected. But I agree on the latency.
Based on above, think about this 'failure scenario' (is reall.. seen this!):
Staging:103 is busy fixing all packages that fall out with the new GCC.. => 100% builds (which does not even mean it works! but well) Staging:105 updates the entire Qt/KDE Stack... BUT: it's never tested against gcc version++;
So even if Staging:103 AND Staging:105 BOTH are 100% green, you CAN NOT accept them together.. at least a full rebuild cycle after taking 'one of the two' in is required.
right. However, what release managers can do is to merge :103 and accept more submissions to :105 at the same point of time.
Whichever you prefer: the 2nd one will feel 'really bad' for having to fix stuff that was not broken before; or worse: having to REFIX packages they fixed before the other update came in.
sure, but that is life in every scm. When I implemented a great feature in my local git repo, but upstream accepted another big pull request before mine, I am the looser. I do not think we can solve that.
Going through devel projects will also be a pain: a 'fix' for gcc version++ on Qt for example needs to get quickly into Staging:103; but it needs also to be in Staging:105 ASAP, to make sure it won't break. This example is SIMPLE to identify... Others are less obvious.
Hm, it could go into both. If it is identical no problems on merging it later into :Factory.
I don't think this 'every big thing needs to go through staging' will help a lot to be honest. What we need more than ever is actually really people taking their packages serious! And communication about possible breakings. Like when we updated glib for example: communication upfront by the team updating it.. and actively supporting 'other packages failing due to that' (the factory status page helps a lot in giving an overview why something failed). But don't expect that one person can fix all the rest because he's updating one package... you might loose that one contributor taking care of a few packages and being willing to help fix others, if he feels he's *responsible* for all the other failings.
This is not about blaming single persons. Everybody would be able to contribute to any staging project. It would for sure not replace communication, but maybe it can help. For example the glib guy could point the other package maintainers to that project and showing what is failing now. Also 3rd people would be able go through all these packages and fix. It is often easy to fix 49 out of 50 failing packages after you understood why package 1 was failing ... So in best case it even saves worktime because you are able to focus on one special problem instead to filter random failures in factory ... -- 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