Awesome, sounds great! Thanks! Weiwei
On Thu, Nov 14, 2024 at 6:03 PM Wilfred Spiegelenburg <[email protected]> wrote: > 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] > >
