On Fri, Mar 02, 2018 at 04:40:03AM +0100, Kevin Kofler wrote: > Kevin Fenzi wrote: > >> Something needs to be done to make the compose process more robust, e.g.: > >> * running createrepo on a stable release, so that we do not have to be > >> able > >> to init a chroot of the target system to compose a repository. A broken > >> dependency, even in systemd or rpm, should NEVER be a reason for the > >> repository to fail to compose. > >> * publishing individual deliverables one at a time, i.e.: > >> 1. compose the repositories, > >> 2. sync the repositories out to the mirrors, > >> 3. build the images (atomic ostrees, live images etc.) one at a time, > >> 4. sync those images that succeeded out to the mirrors, keep the old > >> versions of the other ones (the matching SRPMs are in Koji anyway, > >> so it does not matter if the SRPMs in the tree don't match) > >> etc. > > > > I disagree entirely with the above. I think the solution is to gate > > packages coming into rawhide and hold or reject those that break the > > compose until they are fixed. I think being proactive is VASTLY better > > than being reactive. Not breaking something in the first place is much > > easier to deal with than trying to fix it later. > > And how do you propose doing that? The only reliable way to hold packages > that break the compose would be to actually try to run the whole compose > process after every package build. That just does not scale. The composes > are only daily for a reason. Running a compose for every package build would > use a lot of resources and would also take very long, delaying the tagging > of the package into Rawhide for an insane amount of time (at least hours). Well, do you remember Will Woods' talk at DevConf? They managed to do a compose in a matter of minutes, so down the line this may be doable. In the mean while, baby steps. Yes running fast automated tests won't catch all the issues for every issues it will catch is one that will no need to be dealt with later. Once we have the mechanisms in place to gate packages entering rawhide, it will be easier to improve the gating tools. We could even do as everybody else is doing, start with some tests, fix a bug that got through, add the corresponding tests to prevent it from happening again, repeat... :) Pierre _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
