mirror of
https://git.savannah.gnu.org/git/grub.git
synced 2026-10-22 07:12:39 +00:00
57 lines
2.6 KiB
Plaintext
57 lines
2.6 KiB
Plaintext
-*- 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
|