Patch Submission Policy
NOTE: the maintainers of GNU GRUB are pure volunteers so not financed at all. This means that your assistance is essential to keep the project alive, because their spare time is very limitted.
Basic rules
When you submit a patch, we would like you to follow these rules. Otherwise, we might simply ignore your patch to reduce our load.
Read this page and follow it. If you don't write ChangeLog, we won't accept your patch.
- Only bugfixes are accepted. Any kind of new feature is not accepted. GRUB Legacy is not worth extending any further.
- Describe what your patch does, what your patch is for, what happens without your patch.
The definition of bugfixes
If any existing feature does not work and your patch addresses that problem, it is a bugfix.
If your system is technically impossible to be booted only with existing features and your patch addresses that problem, it is a bugfix.
New features
In principle, we will never accept any new feature for GRUB Legacy. We strongly recommend working on GRUB 2 instead.
If you really need a new feature, there is a way: be a co-maintainer of GRUB Legacy. Our current policy is based on the fact that GRUB Legacy is maintained only by okuji in reality, and his spare time and energy are not infinite. If you wish to maintain such a new feature for a long time, we are ready for accepting any new feature.
The usual reason why we don't accept any new feature is that a patch submitter sends a patch and disappears. You must understand that this is the same as saying that the maintainer should work for the submitter. For the sake of compatibility, increasing features inevitably increases the burden on the maintainers. Considering that GNU GRUB is a volunteer project, this attitude is not fair enough. You should be prepared to help the maintenance process if you want a new feature. It is useful to point out that the cost of maintenance occupies 80% of the whole project in a survey.
Do not fork the project, but join us!
Some people try to fork the project when they are notified that new features are not accepted. This is silly, because someone must maintain such features anyway in forked projects. Then, why not in the original project? If you are willing to maintain new features, you can do this officially.
You know why project forking is usually not good. Now many distributors apply several patches to the original distribution, many bug reports are very specific to each version. And, each distributor fixes problems individually. How inefficient. We should try to concentrate our effort on a single place as much as possible rather than scattering it.