| The Android Open Source Project | 5b1eb06 | 2009-03-03 19:29:32 -0800 | [diff] [blame] | 1 | -*- text -*- |
| 2 | |
| 3 | This is a list of random notes for GRUB maintainers. If you are not a |
| 4 | maintainer, you need to ask maintainers to do these instead of doing |
| 5 | these yourself. |
| 6 | |
| 7 | How to update the online manual: (FIXME: this is obsoelete) |
| 8 | 1. Copy docs/*.texi (excluding "multiboot.texi") to fencepost.gnu.org. |
| 9 | 2. Make a symbolic link from ~mohit/gnudoc/gnudoc_template to the |
| 10 | directory under which *.texi were copied, if the link isn't present. |
| 11 | 3. Run ``~mohit/gnudoc/gendocs.sh grub "GNU GRUB Manual"''. |
| 12 | 4. Copy the contents of the directory ``manual'' to |
| 13 | gnudist.gnu.org:~ftp/gnu/Manuals/grub-VERSION (VERSION is, for |
| 14 | example, 1.0). |
| 15 | 5. Run ``ln -sf grub-VERSION grub'' in gnudist.gnu.org:~ftp/gnu/Manuals. |
| 16 | 6. Run ``cd grub; ln -s grub.html index.html''. |
| 17 | 7. Verify the new online manual with a WWW browser. |
| 18 | 8. Update manual.html by hand. |
| 19 | |
| 20 | How to release a version: |
| 21 | 1. Check out the source tree from the CVS from scratch. |
| 22 | 2. Check if ``make distcheck'' succeeds. |
| 23 | 3. Run ``util/grub-image''. |
| 24 | 4. Check the resulted images, for example, using bochs. |
| 25 | 5. Copy grub-VERSION.tar.gz, grub-VERSION-i386-pc.tar.gz and |
| 26 | grub-VERSION-i386-pc.ext2fs to fencepost.gnu.org:~ftp/gnu/grub. |
| 27 | 6. Move older files in that directory above to the directory ``old'', |
| 28 | if you think they are eyesores. |
| 29 | 7. Post an announcement to bug-grub@gnu.org. It would be a good idea to |
| 30 | send a carbon copy to bug-hurd@gnu.org and |
| 31 | debian-hurd@lists.debian.org. If the announcement is for a stable |
| 32 | version, you can inform info-gnu@gnu.org as well. |
| 33 | 8. Optionally, post an announcement to Freshmeat.net. |
| 34 | |
| 35 | Legal issues: |
| 36 | 1. If a patch is not significant (in size), you don't have to care about |
| 37 | the copyright. |
| 38 | 2. If a patch is significant, you shouldn't apply the patch to the CVS. |
| 39 | Before doing that, you must ask the contributor to assign or disclaim |
| 40 | the copyright. Send ``/gd/gnuorg/request-assign.changes'' or |
| 41 | ``/gd/gnuorg/request-assign.future'' to the contributor, and wait |
| 42 | until the FSF finishes the legal work. |
| 43 | 3. You can check if a contributor has already assigned his/her copyright |
| 44 | to the FSF by looking at ``/gd/gnuorg/copyright.list''. |
| 45 | |
| 46 | What you should have in your mind: |
| 47 | 1. Don't add features unnecessarily! You may think it is a Good Thing to |
| 48 | have more features, but you must be prepared for more burdens. |
| 49 | DO THAT ONLY IF YOU BELIEVE THAT THE FEATURE IS ESSENTIAL. |
| 50 | 2. Don't break backward-compatibility! Don't apply any patch which could |
| 51 | break existing features. Otherwise you would receive a lot of |
| 52 | complaints. DO THAT ONLY IF YOU BELIEVE THAT THE INCOMPATIBILITY IS |
| 53 | INEVITABLE. |
| 54 | 3. Write good code. Be not satisfied with ad hoc workarounds or quick |
| 55 | hacks. NEVER WRITE BAD CODE. |
| 56 | |
| 57 | Resources: |
| 58 | * http://www.gnu.org/prep/maintain_toc.html |
| 59 | * http://www.gnu.org/prep/standards_toc.html |
| 60 | * http://www.gnu.org/server/fsf-html-style-sheet.html |
