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
it takes ages to generate all the Fedora related products like
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
and on fedora. AFAIK, _bodhi_ runs the tests for stable releases,
Rawhide it will be koji directly? Why you don't move all the testing
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
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
> they make it to the compose.
It is not specified, but there will be two sets of tests? One to
move the package to buildroot to build against, and second to move
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.
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org