Am Donnerstag, 14. Juni 2012, 15:32:15 schrieb Dominique Leuenberger a.k.a DimStar:
Quoting Adrian Schröter <adrian(a)suse.de>de>:
Just to draw a picture, such transactions could
be similar to what we do
with maintenance updates. There could be
projects. realease managers would sort the submit requests into them.
is just for binutils & gcc update. It is currently building all factory
packages to see if it has an effect.
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.
got an KDE 4.99 update plus some qt packages. Build is finished,
fine. Could be merged into openSUSE:Factory.
Surely an approach, but timing wise you'll probably get really a low
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 ...
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