Greg Freemyer - 9:34 3.12.13 wrote:
=== - how SR batches are handled? For instance, if I have even just 2 SRs that I know depend on each other but I want them staged because I don't know what else may depend on them. How do I tell OBS to create a staging tree and include both of my SRs. Obviously for KDE or Gnome, these might be very large SR batches.
You write in SR of the lower package (the one that the other one depends on) please create Staging for this and in the second one that it depends on the first). AFAIK currently OBS doesn't handle dependencies between SRs.
=== - I like the idea of every SR (or small SR batch) going through a staging project. But I think we need 2 solutions: short term (hours) staging projects and long term (days/weeks) staging projects.
-- long term staging projects - this has been the focus of discussion, so I will ignore it here.
-- short term (hours) staging projects
I propose every SR (or SR batch) not tagged for long term staging be evaluated for short term staging viability. The criteria could be "causes 5 or less package builds and all of the package builds take less than 1 hour each".
Once a SR / SR batch is tagged for short term staging:
From here
--- create short term staging project - A BtrFS read/write snapshot of factory is created. This should only take a couple seconds
--- Update the affected packages based on the SR / SR batch - I assume a few more seconds
--- Run the build logic and build the updated packages and anything that depends on them - this is the time consumer, put hopefully this class of build can be given top priority.
to here we don't need special workflow as it would be handled by OBS
--- If no build errors, forward original SR / SR batch to factory reviewers and destroy BtrFS snapshot.
--- if build errors, hoover up the build logs from all the builds and attach them to the SR, reject the SR, and destroy the BtrFS snapshot.
If the above is totally automated, it seems the BtrFS snapshot may only live for a an hour or less typically.
With that process it seems the overhead of creating a staging projects is minimal and even single package SRs of leaf packages could be run through a quick staging compile / dependency compile. ===
Not a good idea to hack a new OBS from scratches living next to the official one. And I don't see what should be the difference between the short term and long term ones. Short ones are rejected right away without striving for solution in staging?
-- How many "leaf" SRs per day are there anyway?
No idea.
-- How many simultaneous BtrFS snapshots can exist and still get reasonable performance?
No idea and doesn't matter.
--- If one assumes 10 simultaneous BtrFS snapshots is reasonable to maintain, then a queue could be established to push leaf package staging projects through. If the average leaf staging project lives for 1 hour, then that's 240 SR / SR batches per day that could be treated this way..
Scheduling, building takes some time, there are other stuff, overall I think that we don't need staging for everything (although it might be nice). -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org