On Thu, Mar 07, 2019 at 10:24:00PM +0800, Zamir SUN wrote: > > > On 3/2/19 5:02 PM, Pierre-Yves Chibon wrote: > > On Fri, Mar 01, 2019 at 06:57:48PM -0800, Tom Stellard wrote: > >> On 03/01/2019 01:19 PM, Ben Cotton wrote: > >>> https://fedoraproject.org/wiki/Changes/GatingRawhideSinglePackageUpdates > >>> > >>> == Summary == > >>> We want to gate packages on test results before they can land in > >>> rawhide. This will reduce the amount of broken dependency, > >>> uninstallable packages and broken composes leading to a more stable > >>> rawhide as well as less work on the infrastructure and rel-eng teams > >>> to keep composes working. > >>> > >> > >> Does the gating prevent packages from being tagged at all so that they > >> won't even end up in the buildroot, or does it just gate packages from > >> going into a compose? > > > > It gates the package from entering the buildroot, which will impact the packages > > going into a compose, but as a side effect. > > > > Given it blocks packages from entering buildroot, I wonder if it is a > good idea to start gating whole Rawhide lifetime, I mean, from the > starting of a ready-to-release release branched out of Rawhide? > > My case is, we have a set of packages to update each release. They > cannot do in parallel - they depend on one another. Currently we only > update them in Rawhide, because each package can get into buildroot > shortly after we build it, and we don't need to file a > buildroot-override. Once even packages cannot get into Rawhide > automatically (for example, I need to click a "waive test result" or > something), this is more like a burden. So what you are describing is basically the case of multi-packages update. You want to ship as one packages that depend on each other and should be ship as one unit. The current approach specifically does not support this use case. There are two ways to go about this: - Do not opt-in into the gating (ie: do not add a gating.yaml in your dist-git repo) - Do opt-in but when you need something faster, opt-out, by simply building the package in rawhide-candidate (or its equivalent) directly. > As for the Single build updates vs multi build updates ratio, I don't > quite understand what the number is from - does it comes out of Bodhi? They do yes and indeed as you're mentioning they are informative but likely not fully representative of rawhide. > If it means the updates in Bodhi, I want to mention that, in my case, I > never want to update multi build updates in a stable (or post-freeze) > release. Thus I seldom file multi build updates in bodhi. Especially we > don't need to file Bodhi to get packages into Rawhide at this point, > this maybe misleading in deciding to enable gating for Rawhide. The bodhi updates will be filled automatically and if tests pass (or if there are no gating.yaml) the build will land in rawhide, automatically as well, just as it does today. The point of bodhi is to give us a way to see in which state is a package or why a package that was built did not land in the rawhide buildroot in a place that is accessible to everyone in the community. > As a summarize, I think it is a good idea to have some sort of gating. > But I think we need to think carefully if we do really need to gate Rawhide. I don't think there are so many ways to stabilize rawhide so that compose (for example) pass more often than they fail (there hasn't been a successful rawhide compose in a week). CI and gating is one of them and one that is pretty standard in our industry. Pierre _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
