Hey GRUB community, This RFC discussion is about proposing a less stable repository alongside the current official one.
The issue I'd like to raise is the slow pace of development. While this slow development helps ensure stability, it can also become a barrier to introducing new features, limit opportunities for improvement, and reduce long term project continuity. One potential solution I'd like to propose is to fork the current mainline stable repository and create a "development" or "unstable" repository. This repository could allow patches from contributors to be merged more quickly after careful review by project reviewers, of course. This would: * Encourage broader community collaboration * Allow contributors to gain more development experience * Help us detect and fix bugs earlier, even before the RC (Release Candidate) phase The idea is not to compromise on stability, but to separate stable focused environments (like enterprise distributions) from bleeding-edge development. Distributions focused on stability could continue using the stable branch, while bleeding-edge distros could test the development branch and contribute feedback earlier. We could forward new features and experiments to the development repository, while routing critical fixes and security updates directly to the stable repository. In other words, we need to split GRUB into LTS and mainline or stable and unstable just like other modern software projects do. Which way we do it doesn't matter; what matters is that we open the door for faster, more flexible development. If my idea isn't the best fit, I encourage others to share theirs. I would also like to suggest that we adopt a fixed release schedule. I'm kindly reaching out to project maintainers, contributors, and others involved in GRUB to hear your thoughts on this idea. My observations come from spending time with the project and reflecting on how to keep it moving forward. Right now, we do an excellent job focusing on stability, bug fixes, and security which are all critical. But we also need to think about how to grow, how to innovate, and how to ensure GRUB stays strong into the future. Looking forward to your thoughts, Khaalid _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
