]> git.donarmstrong.com Git - lilypond.git/commitdiff
Docs: minor updates to CG and web.
authorGraham Percival <graham@percival-music.ca>
Sat, 12 Dec 2009 15:52:25 +0000 (15:52 +0000)
committerGraham Percival <graham@percival-music.ca>
Sat, 12 Dec 2009 15:52:25 +0000 (15:52 +0000)
Documentation/contributor/issues.itexi
Documentation/contributor/release-work.itexi
Documentation/web/community.itexi

index 6febab04712710642a751b272ed3f8f662c8c4b5..bab0f040a5fb1ddbecf40da69e276e27cce702a0 100644 (file)
@@ -195,8 +195,7 @@ Once every year or so:
 Checking all regtests: although we have a system for checking the
 regtests between two versions, occasionally a bug will slip
 through the cracks.  It is therefore good to manually examine all
-the regtests twice a year or so (compare the images to the text
-description).
+the regtests (compare the images to the text description).
 
 @item
 Checking all issues: we try to mark each Issue @q{fixed} when we
index ec29945a0572076ababe74d4ad99d66cb127c304..9340d5d2304bfd6813acea43164c8cb9f680f8e7 100644 (file)
@@ -77,8 +77,32 @@ permitted during the stable phase.
 
 A @qq{minor release} means an update of @code{y} in @code{2.x.y}.
 
-email brief summary to info-lilypond
+@enumerate
 
+@item Add a news item to @file{Documentation/web/news-front.itexi}
+
+@item Build release on GUB.
+
+@item Check the regtest comparison in @file{uploads/webtest/} for
+any unintentional breakage.
+
+@item Check if the mingw build contains lilypad.exe; when you find
+that it doesn't, rebuild @code{mingw::lilypond-installer}.  Repeat
+as necessary.
+
+@item If any work was done on GUB since the last release, upload
+binaries to a temporary location, ask for feedback, and wait a day
+or two in case there's any major problems.
+
+@item Upload release from GUB.
+
+@item Update @file{VERSION} in lilypond git.
+
+@item Wait a few hours for the website to update.
+
+@item Email release notice to @code{info-lilypond}
+
+@end enumerate
 
 
 @node Major release checklist
@@ -173,19 +197,12 @@ To build GUB:
 Run the following (from the gub/ dir):
 
 @example
-make -f lilypond.make update-versions
+make lilypond
 @end example
 
 @item
 If you do not have the previous release test-output tarball, download
-it and put it in @code{uploads/}
-
-@item
-Run:
-
-@example
-make lilypond
-@end example
+it and put it in @code{regtests/}
 
 @end itemize
 
@@ -193,34 +210,17 @@ To upload:
 
 @itemize
 
-@item Remove the "t" from the rsync command in test-lily/rsync-lily-doc.py
+@item If you're not user @code{graham} on the webserver, remove
+the "t" from the rsync command in
+@file{test-lily/rsync-lily-doc.py}
 
-@item run:
+@item Probably run the following command.  Look the output of
+@code{make lilypond} in case it's different.
 
 @example
-python test-lily/upload.py --branch=master --url git://git.sv.gnu.org/lilypond.git --execute
+make lilypond-upload LILYPOND_BRANCH=master LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git
 @end example
 
 @end itemize
 
 
-@subheading Policy notes
-
-@itemize
-
-@item
-Build with GUB, and if it's a stable release, check the regtests.
-
-@item
-Upload the tarballs and sh scripts.
-
-@item
-(if major)
-Branch MASTER to stable/2.x.
-
-@item
-Make announcement.
-
-@end itemize
-
-
index d90b76a1442c5d566219f1663254ac5aff625a40..51bef5edfa2af94fb638693edd3c5c140b8d8b2e 100644 (file)
@@ -655,9 +655,10 @@ a large, (mostly) stable project.  In order to help new
 contributors, and to keep the whole system (mostly) stable, we
 have written a manual for contributors.
 
-This manual is not intended to be read sequentially; new contributors
-should only read the sections which are relevant to them.  For more
-information about different jobs, see @ref{Help us}.
+@warning{This manual is not intended to be read sequentially; new
+contributors should only read the sections which are relevant to
+them.  For more information about different jobs, see
+@ref{Help us}.}
 
 @divClass{keep-bullets}
 @itemize