vbatts/grub
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Write several notes for maintainers.

Browse source
This commit is contained in:
okuji 2002-06-24 12:17:41 +00:00
parent fada891e5c
commit f711a2453a
4 changed files with 62 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

4
ChangeLog
View file

@ -1,3 +1,7 @@
2002-06-24 Yoshinori K. Okuji <okuji@enbug.org>
* MAINTENANCE: New file.
2002-06-15 Yoshinori K. Okuji <okuji@enbug.org>
* stage2/disk_io.c [SUPPORT_NETBOOT] (GRUB): Defined.

56
MAINTENANCE Normal file
View file

@ -0,0 +1,56 @@
-*- 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

2
Makefile.am
View file

@ -1,3 +1,3 @@
# Do not change this order if you don't know what you are doing.
SUBDIRS = netboot stage2 stage1 lib grub util docs
EXTRA_DIST = BUGS
EXTRA_DIST = BUGS MAINTENANCE

2
Makefile.in
View file

@ -89,7 +89,7 @@ host_vendor = @host_vendor@
install_sh = @install_sh@
SUBDIRS = netboot stage2 stage1 lib grub util docs
EXTRA_DIST = BUGS
EXTRA_DIST = BUGS MAINTENANCE
subdir = .
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs