Contributing changes to GRUB
Contributing changes to GRUB 2 is welcomed activity. However we have a bit of control what kind of changes will be accepted to GRUB 2. Therefore it is important to discuss your changes on grub-devel mailing list (see MailingLists). On this page there are some basic details on the development process and activities.
First of all you should come up with the idea yourself what you want to contribute. If you do not have that beforehand you are advised to study this wiki and try GRUB 2 out to see what you think is missing from there.
Here are some pointers:
And the rest of the wiki
If you intended to make changes to GRUB Legacy (<0.97) those are not accepted anymore.
Getting started
1. Always use latest GRUB 2 source code. So get that first.
For developers it is recommended always to use the newest development version of GRUB 2. If development takes a long period of time, please remember to keep in sync with newest developments regularly so it is much easier to integrate your change in the future. GRUB 2 is being developed on SVN repository.
Please check Savannah's GRUB project page for details how to get newest SVN: GRUB 2 SVN Repository
2. Compile it and try it out.
It is always good idea to first see that things work somehow and after that to start to implement new features or develop fixes to bugs.
3. Study the code.
There are sometimes odd ways to do things in GRUB 2 code base. This is mainly related to limited environment where GRUB 2 is being executed. You usually do not need to understand it all so it is better to only try to look at places that relates to your work. Please do not hesitate to ask for help if there is something that you do not understand.
4. Develop a new feature.
Now that you know what to do and how it should work in GRUB 2 code base, please be free to develop it. If you have not so far announced your idea on grub-devel mailing list, please do it now. This is to make sure you are not wasting your time working on the solution that will not be integrated to GRUB 2 code base.
You might want to study our coding style before starting to development so you do not need to change much of the code when your patch is being reviewed. (see CodingStyle)
For every accepted patch there has to exist a ChangeLog entry. Our ChangeLog consist of changes within source code and are not describing about what the change logically does. Please see examples from previous entries.
Also remember that GRUB 2 is licensed under GPLv3 license and that usually means that you are not allowed to copy pieces of code from other projects. Even if the source project's license would be compatible with GPLv3, please discuss it beforehand on grub-devel mailing list.
5. Test your change.
Test that your change works properly. Try it out couple of times. Preferably on different systems. And try to find problems from it.
6. Publish your change.
When you are happy with your change. First make sure it is compilable with latest development version of GRUB 2. After that please send a patch to grub-devel for review. Please describe in your email why you made the change, what it changes and so on. Please be prepared to receive even discouraging comments about your patch. There is usually at least something that needs to be improved in every patch.
Please use unified diff to make your patch (good match of arguments for diff is -pruN).
7. Respond to received feedback.
If you are asked to modify your patch, please do that and resubmit it for review. If your change is large you are required to submit a copyright agreement to FSF. Please keep in mind that if you are asked to submit for copyright agreement, process can take some time and is mandatory in order to get your changes integrated.
If you are not on grub-devel to respond to questions, most likely your patch will not be accepted. Also if there comes problems from your changes later on, it would be preferably that you also fix the problem. So stay around for a while.
8. Your patch is accepted.
Good job! Your patch will no be integrated to GRUB 2 main line and if it didn't break a thing it will be publically available when next release will be done.
Now you are welcomed to do further improvements
Typical Developer Experience
The typical experience for a developer in this project is the following:
- You find yourself wanting to do something (e.g. fixing a bug).
- You show some result in the mailing list or the IRC.
- You are getting to be known to other developers.
- You accumulate significant amount of contribution, so copyright assignment is processed.
- You are free to check in your changes by your own, legally speaking.
At this point, it is rather annoying that you ought to ask somebody else every change to be checked in. For efficiency, it is far better, if you can commit it yourself. Therefore, our policy is to give you the write permission to our official repository, once you have shown your skill and will, and the FSF clerks have dealt with your copyright assignment.
When you are approved for write access to project's files
As you might know, GRUB is hosted on Savannah, thus the membership is managed by Savannah. This means that, if you want to be a member of this project:
- You need to create your own account on Savannah.
You can submit Request for Inclusion from My Groups on Savannah.
Then, one of the admins can approve your request, and you will be a member. If you don't want to use the Savannah interface to submit a request, you can simply notify the admins by email or something else, alternatively. But you still need to create an account beforehand.
NOTE: we sometimes receive a Request for Inclusion from an unknown person. In this case, the request would be just discarded, since it is too dangerous to allow a stranger to be a member, which automatically gives him a commit right to the repository, both for a legal reason and for a technical reason.
If your intention is to just get started, please do not submit a inclusion request. Instead, please subscribe to the mailing list, and communicate first (e.g. sending a patch, asking a question, commenting on another message...).