El mar, 21-02-2017 a las 07:43 +0100, Pavel Raiskup escribió: > 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? That is part of it. but it is about making Rawhide be suitable for daily use while allowing the change to continue on at a rapid pace. Historically we have had to spend a lot of time leading up to branching just getting rawhide to be able to even compose. We are better now that we do full composes nightly. however we hit periods where a change lands that breaks things and it takes manual effort to get it all sorted. which we normally do by kicking builds out and filing bugs. something that can be automated. > > == 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? There will be no testing in koji, we will be using taskotron and the existing testing frameworks. The testing will then manage the tagging of builds in koji. > From this perspective, this sounds like we invent sub-optimal > (release > engineering) and confusing (for packager's) workflow. > > > Over time we can enable extra testing to gate the build going into > > rawhide. Builds will land in the buildroot to be built against > > before > > they make it to the compose. > > 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? I will update the change for this, the builds will land in the buildroot immediately, the gating is to get into the rawhide release. so there will only be one set of testing. Dennis > Pavel > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
