On Mon, Feb 20, 2017 at 11:26:00PM -0800, Adam Williamson wrote: > On Tue, 2017-02-21 at 07:43 +0100, Pavel Raiskup wrote: > > On Monday, February 20, 2017 6:44:50 PM CET Jan Kurik wrote: > > > Fedora will no longer produce Alpha releases. > > > > As a side-effect of making rawhide "alpha". That doesn't sound bad. > > > > After seeing Denis's talk on devconf, I think I understand the motivation: > > it takes ages to generate all the Fedora related products like images. > > Right? > > Well, yes, it does, but that's not so much a *motivation* for this as > one of the factors that complicates the implementation. The motivation > is simply to have a better quality product. > > > > == Detailed Description == > > > By gating Rawhide builds from landing in the compose and gating the > > > publication of composes on automated test results we will ensure Rawhide will > > > always be at Alpha quality. This will make it more generally useful to people > > > as a daily driver and development platform, and mean we no longer need to go > > > through the process of building, testing and shipping Alpha releases. The > > > initial testing will be ensuring that a package is installable and that it > > > does not break existing packages installation. > > > > Ok, I'm curious why we'll treat CI/testing differently on stable releases > > and on fedora. AFAIK, _bodhi_ runs the tests for stable releases, and for > > Rawhide it will be koji directly? Why you don't move all the testing to koji > > then? > > Neither Bodhi nor Koji runs any tests (except for the %check section of > a package build, I guess). The package tests are run by Taskotron. > Right now they are run for every Koji build, but adjusting the triggers > is fairly trivial, if we want to trigger the tests in any other way. > You can see the trigger code at > https://pagure.io/taskotron/taskotron-trigger/blob/develop/f/jobtriggers . > > You can *see* the test results from the Bodhi web interface, but that > doesn't mean Bodhi is running the tests or really that the tests have > anything to do with Bodhi. That's just Bodhi's client-side Javascript > querying ResultsDB for any test results marked as being related to the > packages in the update. (Out of interest, if I manage to get my current > side project of having openQA run tests on critpath updates up and > running, those results will just 'magically' show up in Bodhi as well, > since all Bodhi is doing is querying ResultsDB). But ResultDB does not have an UI people are used to to get information about new update, while Bodhi does. This is exactly why I think we should gate rawhide update in bodhi, we need a place to provide feedback to the packagers about why an update went through into rawhide or why it didn't. Bodhi even offers the possibility to edit and group updates then. The whole CI workflow relies on the possibility to give and receive feedback, so we need a place to do that. FMN is one, but in itself it is not sufficient, people don't necessarily use it, ignore it, delete the notifications and it is not public. If you build and update and for some reason I end up two days later wondering why it didn't hit rawhide, I need a place to go and have this info. ResultDB isn't this place. Bodhi on the other hand is public and stable. Anyone can access it and see why an update wasn't pushed (because tests Y and Z failed) and for the packagers they know they can always find back this information there. > > It is not specified, but there will be two sets of tests? One to even > > move the package to buildroot to build against, and second to move the > > package to rawhide repo, right? Then what about to do apply the same > > process for updates-testing? > > There are already quite a lot of plans in place relating to this. Bodhi > is only one possible integration point for tests. The major focus at > present is to deploy a Pagure instance on top of dist-git, as that > provides another point at which we can provide a proper test feedback > loop. Right now, we already run package tests on every Koji build and > we could in theory run package tests on every git commit (as we know > when dist-git commits happen), but there is no system through which can > do any kind of useful feedback loop or gating based on the results. > Pagure-for-dist-git would provide that. Pagure would provide this at the package leve, Bodhi could do it at the update level. Actually, pagure should be offering feedback *before* the merge has occurred and the package even been built in Fedora, while bodhi will provide feedback *after* it was built but *before* it is pushed. I really believe we ought to gate update in bodhi, just with the tooling to automatically push them as the test results are returned. Similarly, we should provide feedback on pagure for each PR offering a change to a spec file. Pierre _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
