grub2-dev: Getting started
1
1 4.1 Getting started
1 ===================
1
1 * Always use latest GRUB 2 source code. So get that first.
1
1 For developers it is recommended always to use the newest
1 development version of GRUB 2. If development takes a long period
1 of time, please remember to keep in sync with newest developments
1 regularly so it is much easier to integrate your change in the
1 future. GRUB 2 is being developed in a GIT repository.
1
1 Please check Savannah's GRUB project page for details how to get
1 newest git: GRUB 2 git Repository
1 (https://savannah.gnu.org/git/?group=grub)
1
1 * Compile it and try it out.
1
1 It is always good idea to first see that things work somehow and
1 after that to start to implement new features or develop fixes to
1 bugs.
1
1 * Study the code.
1
1 There are sometimes odd ways to do things in GRUB 2 code base.
1 This is mainly related to limited environment where GRUB 2 is being
1 executed. You usually do not need to understand it all so it is
1 better to only try to look at places that relates to your work.
1 Please do not hesitate to ask for help if there is something that
1 you do not understand.
1
1 * Develop a new feature.
1
1 Now that you know what to do and how it should work in GRUB 2 code
1 base, please be free to develop it. If you have not so far
1 announced your idea on grub-devel mailing list, please do it now.
1 This is to make sure you are not wasting your time working on the
1 solution that will not be integrated to GRUB 2 code base.
1
1 You might want to study our coding style before starting
1 development so you do not need to change much of the code when your
1 patch is being reviewed. (see ⇒Coding style)
1
1 For every accepted patch there has to exist a ChangeLog entry. Our
1 ChangeLog consist of changes within source code and are not
1 describing about what the change logically does. Please see
1 examples from previous entries.
1
1 Also remember that GRUB 2 is licensed under GPLv3 license and that
1 usually means that you are not allowed to copy pieces of code from
1 other projects. Even if the source project's license would be
1 compatible with GPLv3, please discuss it beforehand on grub-devel
1 mailing list.
1
1 * Test your change.
1
1 Test that your change works properly. Try it out a couple of
1 times, preferably on different systems, and try to find problems
1 with it.
1
1 * Publish your change.
1
1 When you are happy with your change, first make sure it is
1 compilable with latest development version of GRUB 2. After that
1 please send a patch to grub-devel for review. Please describe in
1 your email why you made the change, what it changes and so on.
1 Please be prepared to receive even discouraging comments about your
1 patch. There is usually at least something that needs to be
1 improved in every patch.
1
1 Please use unified diff to make your patch (good match of arguments
1 for diff is '-pruN').
1
1 * Respond to received feedback.
1
1 If you are asked to modify your patch, please do that and resubmit
1 it for review. If your change is large you are required to submit
1 a copyright agreement to FSF. Please keep in mind that if you are
1 asked to submit for copyright agreement, process can take some time
1 and is mandatory in order to get your changes integrated.
1
1 If you are not on grub-devel to respond to questions, most likely
1 your patch will not be accepted. Also if problems arise from your
1 changes later on, it would be preferable that you also fix the
1 problem. So stay around for a while.
1
1 * Your patch is accepted.
1
1 Good job! Your patch will now be integrated into GRUB 2 mainline,
1 and if it didn't break anything it will be publicly available in
1 the next release.
1
1 Now you are welcome to do further improvements :)
1