On 03/01/2018 07:40 PM, Kevin Kofler wrote: > 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). The vast majority of issues are related to a package update causing broken deps for something needed in something release blocking. So, I would start there and setup gating to check for broken deps and require waving that test or fixing the deps. The next most common issue is core tools changing that we use to compose (lorax, anaconda, kernel, glibc). For those we are intending to try and make 'quick composes' that compose something quickly and test it to catch common/simple issues. Then we go from there. > If you propose just doing some fast automated tests catching some issues, > that will never reliably catch all issues breaking the composes, and so my > proposals to increase the robustness of the compose process will still be > relevant. The only way to know for sure whether the compose will succeed is > to run it (and even that will not necessarily catch non-deterministic > failures). The problems I see with just shipping whatever we compose: * It means things will likely be broken longer as there is less urgency to fix them quickly. * There's cascading issues where issue A stops composing of items 1, 2, 3, 4 and each of those have further issues, so it means we don't even know what all is broken. * Shipping things out means we can't easily untag or revert packages with using Epoch's much more commonly. * It will mean we are not in fact always shipping alpha quality, we could be shipping anything. * reactive just is a lot harder in the end, IMHO. > It is just defensive programming to not fail the whole process on any small > issue that you cannot avoid (with the resources that are available). Not if you aren't sure of the thing you are producing. > > By the way, in the distant past, if some (or even all) live image compose(s) > failed, the compose would just get published without that/those live > image(s) (in the worst case, with an empty Live directory). Not ideal (and > keeping the last successful build of each image as I suggest doing would be > an improvement on that, Koji should be enough to fulfill the copyleft > licenses' source distribution requirements), but at least the package repo > went out a lot more often than nowadays. Well, I think the last few weeks have been particularly bad... it's not always like this (or even ever). > > > I am not asking you to ship bug-free composes. (I know that's impossible. > ;-) ) I am just asking you to take less than a week to get a compose with an > already built critical fix out. :-) Well, I am not sure I would call that a critical fix, but to each their own. kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
