elease
> process and its verification in a nightly bases then we shouldn't have
> any major surprises.
>
In my ideal world, cutting a release is a formality, and release
verification never fails because we essentially release and verify every
night. We should work towards that.
lease will be blocked.
>
>
>
> I sill think that implementing continuous (nightly) release
> verification is needed and maintained. If we keep green
> release verification, we'll always be able to cut a RC
> without problems.
I would like this approach more. If we could sim
tion test failure, our release will be blocked.
I sill think that implementing continuous (nightly) release
verification is needed and maintained. If we keep green
release verification, we'll always be able to cut a RC
without problems.
Thanks,
--
kou
In
"[Proposal] Modify release
Agreed, there are multiple issues to resolve in order for our release
process to be manageable and scalable for the project. This procedural
change is not a silver bullet, and if we agree to it, it doesn't mean that
our releases are "fixed". But it's the only change where the solution is a
discussi
I'm OK with moving to source only releases, but we need to take a step
back and consider how our CI/CD is failing to notify us in a suitably
timely and automated way about the packages being broken. For example,
the fact that we had 2 failed RCs as the result of packaging issues
points to a broken
Hi all,
Over the past year, there's been a lot of discussion around the challenges
we face as a project in doing releases. Because they are costly to do, we
don't do them often; because we don't do them often, they become even
costlier.
There are only a small number of people (PMC members with GPG
