| -*- text -*- |
| |
| How to update the online manual: |
| 1. Copy docs/*.texi (excluding "multiboot.texi") to fencepost.gnu.org. |
| 2. Make a symbolic link from ~mohit/gnudoc/gnudoc_template to the |
| directory under which *.texi were copied, if the link isn't present. |
| 3. Run ``~mohit/gnudoc/gendocs.sh grub "GNU GRUB Manual"''. |
| 4. Copy the contents of the directory ``manual'' to |
| gnudist.gnu.org:~ftp/gnu/Manuals/grub-VERSION (VERSION is, for |
| example, 1.0). |
| 5. Run ``ln -sf grub-VERSION grub'' in gnudist.gnu.org:~ftp/gnu/Manuals. |
| 6. Run ``cd grub; ln -s grub.html index.html''. |
| 7. Verify the new online manual with a WWW browser. |
| 8. Update manual.html by hand. |
| |
| How to release a version: |
| 1. Check out the source tree from the CVS from scratch. |
| 2. Check if ``make distcheck'' succeeds. |
| 3. Run ``util/grub-image''. |
| 4. Check the resulted images, for example, using bochs. |
| 5. Copy grub-VERSION.tar.gz, grub-VERSION-i386-pc.tar.gz and |
| grub-VERSION-i386-pc.ext2fs to fencepost.gnu.org:~ftp/gnu/grub. |
| 6. Move older files in that directory above to the directory ``old'', |
| if you think they are eyesores. |
| 7. Post an announcement to bug-grub@gnu.org. It would be a good idea to |
| send a carbon copy to bug-hurd@gnu.org and |
| debian-hurd@lists.debian.org. If the announcement is for a stable |
| version, you can inform info-gnu@gnu.org as well. |
| 8. Optionally, post an announcement to Freshmeat.net. |
| |
| Legal issues: |
| 1. If a patch is not significant (in size), you don't have to care about |
| the copyright. |
| 2. If a patch is significant, you shouldn't apply the patch to the CVS. |
| Before doing that, you must ask the contributor to assign or disclaim |
| the copyright. Send ``/gd/gnuorg/request-assign.changes'' or |
| ``/gd/gnuorg/request-assign.future'' to the contributor, and wait |
| until the FSF finishes the legal work. |
| 3. You can check if a contributor has already assigned his/her copyright |
| to the FSF by looking at ``/gd/gnuorg/copyright.list''. |
| |
| What you should have in your mind: |
| 1. Don't add features unnecessarily! You may think it is a Good Thing to |
| have more features, but you must be prepared for more burdens. |
| DO THAT ONLY IF YOU BELIEVE THAT THE FEATURE IS ESSENTIAL. |
| 2. Don't break backward-compatibility! Don't apply any patch which could |
| break existing features. Otherwise you would receive a lot of |
| complaints. DO THAT ONLY IF YOU BELIEVE THAT THE INCOMPATIBILITY IS |
| INEVITABLE. |
| 3. Write good code. Be not satisfied with ad hoc workarounds or quick |
| hacks. NEVER WRITE BAD CODE. |
| |
| Resources: |
| * http://www.gnu.org/prep/maintain_toc.html |
| * http://www.gnu.org/prep/standards_toc.html |
| * http://www.gnu.org/server/fsf-html-style-sheet.html |