4.1 Getting started

• 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 in a GIT repository.

  Please check Savannah’s GRUB project page for details how to get newest git: GRUB 2 git Repository

• 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.

• 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.

• 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 development so you do not need to change much of the code when your patch is being reviewed. (see Coding style)

  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.

• Test your change.

  Test that your change works properly. Try it out a couple of times, preferably on different systems, and try to find problems with it.

• 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’).

• 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 problems arise from your changes later on, it would be preferable that you also fix the problem. So stay around for a while.

• Your patch is accepted.

  Good job! Your patch will now be integrated into GRUB 2 mainline, and if it didn’t break anything it will be publicly available in the next release.

  Now you are welcome to do further improvements :)