Hi Wilfred

Recently I had some discussion with Shravan Achar and Junyan Lin, and we
are thinking about helping
the community to have some sort of pre-release tests, the objective is to
run the pre-release builds on a
simulated or a real cluster with auto-scaling enabled, run some synthetic
workloads, scheduled ones at
certain scale, e.g few hundreds to 1k nodes. Use that to validate a release
if it is ready for production.
Would that idea fit into this?

Weiwei

On Wed, Nov 13, 2024 at 6:57 PM Wilfred Spiegelenburg <[email protected]>
wrote:

> Hi all,
>
> While some of us were at CoC we talked about the release cycle.
> The current cycle is really short as we branch and start the creation
> of the release at almost the same time. This does not leave time to
> check if the release is in a decent state.
>
> The proposal is to extend the time that we have between branching and
> starting a release.
> That will give everyone more time to test the release and check its
> stability.
> From the moment that the branch is created only fixes allowed into the
> branch are linked to:
> * CVEs
> * Stopper bugs
> * Backwards compatibility fixes
> * Build related fixes
> New features and or other minor issues will not be allowed into the
> branch. Any fixes made in the branch will follow the normal procedure
> of commit into master first and then cherry-pick into the branch.
> Committers will need to assess if the change must be backported into
> the release branch.
>
> The time between branching and starting the release is flexible. No
> fixed time is currently proposed but we probably should set a minimum
> one at least. For example, a minimum of 2 or 4 weeks between branching
> and starting the release.
> After branching some artefacts should be generated for testing. There
> are two options:
> * source release
> * convenience binaries in the form of docker images
>
> Both options are possible. The choice depends on the community's
> preference.
> Whatever is provided will be removed after we start the release voting.
> Running a pre-release like this in production is never recommended.
>
> Wilfred
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to