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 (Discussions or follow activities on it actively). 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 policy of doing X releases a year was there - who would enforce them, who would drive them? And what happens if we as community miss that, I think 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're 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. I don't think it's a bad thing. With what other opensource communities like Python have done with the whole v2 vs v3 transition (and they continue to do that within 3.10 and 3.10+), it's much better we don't disrupt the product too much for our users. It has both the legacy and pedigree of a product, with its features, benefits and issues. The project is in its plateau of productivity so this isn't surprising we aren't changing much, many of us largely users may not want major disruptions, for users CloudStack must just continue work and continue to be boring. What is practical for the community will most likely happen anyway, 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 and acceptable for the wider community. I think 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). That said, I would encourage anything that helps improve CloudStack adoptability by developers, but it's the users I tend to include more towards. GitHub link: https://github.com/apache/cloudstack/discussions/8970#discussioncomment-9747899 ---- This is an automatically sent email for users@cloudstack.apache.org. To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org
