Hi Fabricio, Thank you ! I appreciate your openness and willingness to support.
I would also be happy to serve as the RM for the 4.23 release. If you’re comfortable with it, we can certainly have you involved in the discussions and ongoing updates, so you can get familiar with the release process and contribute where it makes sense. Please feel free to share your thoughts, and thanks again Kind regards, Wei On Tue, Dec 16, 2025 at 2:13 PM Fabricio Duarte < [email protected]> wrote: > Hi Wei, > > I am open to start with a minor release if that is what the community > thinks is better. > > With that said, I am still available and would be happy to support the > RM for v23 in order to get used to the release process. Whoever takes on > the next major can ping me either on the Slack community or on GitHub if > there is anything that I can help with. > > Regards, > Fabricio > > On 12/15/25 15:28, Wei ZHOU wrote: > > Hi Fabricio, > > > > Thanks for volunteering. > > > > Since this would be your first time in the RM role, it might be a great > > opportunity to start with a minor release. > > Would you be open to waiting and taking on the next minor release instead > > (for example, 4.20.4 or 4.22.2)? This will help you get familiar with the > > process. > > > > What do you think? > > > > > > Kind regards, > > Wei > > > > > > On Mon, Dec 15, 2025 at 12:49 PM Fabricio Duarte < > > [email protected]> wrote: > > > >> Hey all, > >> > >> I would like to volunteer as the RM for v23. > >> > >> I do not have a previous experience managing the community's release, > >> but the guidelines linked by Daan seem clear enough for me. Also, I can > >> get support from other members of the community if needed. > >> > >> My idea is to release v23 around the last week of May, so that we can > >> get 2 major versions in 2026 with around 6.5 months for the development > >> of each version. The timeline for this would be the following: > >> > >> - Until May 3rd: accept new features, bug fixes and improvements. > >> - May 4th: freeze the main branch. From this point, we would only accept > >> critical/blocker fixes. > >> - May 11th: cut RC1 and start the vote (1-3 weeks to work on the next > >> RCs if necessary). > >> > >> What does everyone think? > >> > >> Regards, > >> Fabricio > >> > >> On 2025/12/11 11:54:32 Daan Hoogland wrote: > >> > devs (and users), Call me impatient, but I don't want us falling > out of > >> > rhythm. We already have 'kind of' consensus on the next few > releases; > >> 4.20.3 > >> > , -22.1 and -23. Do people agree with that assessment? next question > >> > obviously being; are there any volunteers to take on the RM work for > >> those? > >> > (Being a PMC member helps but is definitely not a requirement, as > there > >> > will be plenty of support) And if you volunteer, what are the > >> timelines you > >> > would propose? > >> > > >> > my idea was: > >> > - 20.3 february > >> > - 22.1 march > >> > - 23 may , but the RM is to have a word in that of course > >> > The procedures around releases are a kind of tribal knowledge though > >> there > >> > are some guides[1][2][3]. It would help if you are also willing to > help > >> > kristalising and automating these; [1] > >> > > >> > >> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Management+Guidelines%3A+Effective+CloudStack+Release+Manager > >> > [2] > >> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure > >> > [3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS > >> > > >> > -- > >> > Daan > >> > > >> >
