|
1.1.1
by Matt Zimmerman
Import upstream version 0.95+cvs20040624 |
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
|