On Thu, Mar 7, 2019 at 10:07 AM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote: > > 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. > I hate to be the downer here, but I'm generally opposed to this idea as it stands. My ability to develop against Rawhide is principally centered around the fact I can push packages and have them depend on each other. Today, there is no freely accessible way for people to atomically merge changes into the distribution. There's no way for people to freely create spaces to do a bunch of work on a bunch of packages at once and then merge it. We kind of fake this by having to ask releng to grant unto a packager or packagers a side-tag, which work is done there, and then it's merged back into the distribution. But that model has only worked so far because we have nothing like this in place for Rawhide, so we can push all the stuff there, make sure it works, and then merge it into branches. This is how KDE updates are done, for example. And occasionally, the GNOME desktop is updated in the same manner. The fatal misunderstanding here is that people think there's a distinction between "single" and "multi" updates in Rawhide, when in fact that doesn't exist. This proposal is doomed to failure because it assumes stable updates workflows translate to development workflows. And they don't. The reason why single updates are more common is because people are ever-so-slightly more cautious, and huge rebuilds or revdep rebuilds don't happen in stable releases. It doesn't help that the workflow in Fedora makes multi-package updates rather painful, but I don't think anyone cares enough to fix that, either... And I still believe Bodhi is a bad place to do this, because you've still allowed the package to succeed building into the distribution, but I think I won't win on this point. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
