usr/src/grub/grub-0.97/MAINTENANCE
author Christopher Siden <chris.siden@delphix.com>
Mon, 21 May 2012 12:11:39 -0700
changeset 13700 2889e2596bd6
parent 8044 b3af80bbf173
permissions -rw-r--r--
2619 asynchronous destruction of ZFS file systems 2747 SPA versioning with zfs feature flags Reviewed by: Matt Ahrens <[email protected]> Reviewed by: George Wilson <[email protected]> Reviewed by: Richard Lowe <[email protected]> Reviewed by: Dan Kruchinin <[email protected]> Approved by: Eric Schrock <[email protected]>

-*- text -*-

This is a list of random notes for GRUB maintainers. If you are not a
maintainer, you need to ask maintainers to do these instead of doing
these yourself.

How to update the online manual: (FIXME: this is obsoelete)
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 [email protected]. It would be a good idea to
   send a carbon copy to [email protected] and
   [email protected]. If the announcement is for a stable
   version, you can inform [email protected] 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