GitHub user rohityadavcloud edited a comment on the discussion: Define a release schedule for the project
Github Discussions isn't the right place to discuss project governance related matters, but may be used for discussions and to build initial consensus; it was enabled only as a platform to support user-forum interactions. If the intention is/was to only build consensus, then fine - but many PMCs and other stakeholders aren't on Github. Releases, project policy for changes, modernising codebase, I believe there they must be discussed on the dev@ ML. Personally, I think we've well-defined project bylaws and release process that works for me (and perhaps many of us) and I'm not very interested 'currently' to change them, but on convincing arguments I (and others) may participate and help support proposed changes. We generally target two major and two minor releases every year for the CloudStack project and sub-projects releases are on need-basis. However, even if a hard of doing X releases a year was there - who would drive them? And what happens if we miss, there is no way to ensure or enforce that. I appreciate the intentions but it's not practical to pull off or to "ensure" it happens even if there was any policy, protocol, what have you, in place whether it's around releases or disruptive changes. Nobody is stopping any PMC or committers to do a release or lead an initiative; but releases cost time, energy and bandwidth, so many of cannot commit full-time on this to "ensure" they happen but only make our best attempt. I wouldn't consider if Joao or Daniel or others want to do more releases, go make it happen and update https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases These are whole variety of good remarks and thoughts in some other comments, but they don't converge on specific issues related to release schedule. However, I sense some new features or improvements can enable better DB upgrades via (new) framework/tooling that could assist better release management and upgrades. The following is my views on some of the things mentioned; CloudStack indeed can benefit from codebase modernisation, and we're already doing that. But it cannot be replaced overnight, such changes can only be iterative and discussed on case-by-case basis as a separate initiative/proposal/idea. Some changes may be beneficial but we would need to be careful with changes that disrupt users upgrades, integrations and expectations. Community is generally good at maintenance but not with new features or disrupting the codebase in its entirety, which would require willingness of sponsors and employers to fund their people's time and bandwidth on such projects. While we've still on 4.x, CloudStack of 2024 isn't same as that of 2012, it's a massively different, polished and improved project & product with more room to go. It has both the legacy and pedigree of a product, with its features, benefits and issues. We do have a well defined project bylaws and release process, I think they're enough for now to govern and manage the project going further. The project is in its plateau of productivity so this isn't surprising and many of us including users want disruptions, for users CloudStack must just work and continue to be boring. What is practical will most likely happen, we must continue to exercise patience, develop soft skills, learn to build consensus and support and work with others to make such ideas happen. Coding is a small part in what it takes to drive such changes and make them sustainable. Any large project such as ours, in however, whatever standards it must use is difficult to onboard new developers, we aren't unique in that way. For supporting CloudStack development learning/training, we have a [self-learning courseware for aspiring developers](https://github.com/shapeblue/hackerbook). GitHub link: https://github.com/apache/cloudstack/discussions/8970#discussioncomment-9747899 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
