Weiwei, Yes that is exactly why we need to extend the time between creating the branches and the first real release candidate. It will allow us to run these kinds of tests, even if it takes multiple days to run and analyse them.
You have seen the same issues as we all see and as a community we need to do better in this area. Wilfred On Fri, 15 Nov 2024 at 09:56, Weiwei Yang <[email protected]> wrote: > > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
