I appreciate your concern about pace of development and share them. However maintaining what is effectively 2 versions is twice as much effort and would only slow down both versions. We are already discussing among maintainers how we can improve the state of affairs but don't have anything ready for announcement.
Regards Vladimir 'phcoder' Serbinenko Le mar. 27 mai 2025, 22:39, Khalid Ali <khaliidca...@gmail.com> a écrit : > 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 >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
