moth writing cleanup

3 files changed, 58 insertions, 123 deletions

diff --git a/contributing/web_pages/news.mdwn b/contributing/web_pages/news.mdwn
index a700c3ad..39d9dbde 100644
--- a/contributing/web_pages/news.mdwn
+++ b/contributing/web_pages/news.mdwn
@@ -11,100 +11,31 @@ License|/fdl]]."]]"""]]
 [[!meta title="""How to prepare and publish "a month of the Hurd" for the last
 month"""]]
 
-We prepare *a month of the Hurd* in a public git branch (`master-news_next`),
-and merge that one into `master` once we want to publish the news.  The idea is
-to record to-be-published changes on that branch at they time they arise, and
+We prepare *A Month of the Hurd* in the file [[contributing/web_pages/news/news_moth_next]].  The idea is
+to record to-be-published changes in that file at they time they arise, and
 then publish them en bloc at the end of the month.
 
-As this is done on a separate branch, there are two options: you can have
-separate repositories (*clones*, or *checkouts*; what you get from `git clone`)
-for the `master` and `master-news_next` branches, or you can deal with both in
-the same repository.  Having separate repositories you don't have to remember
-which branch you're on, and don't have to switch between branches before
-beginning to edit files, and it doesn't matter -- as no switching between
-branches is needed -- if you have uncomitted changes to some files.  On the
-other hand, you may want to keep it all in one repository, to save disk space,
-and for shuffling different branches' commits being (a bit) easier.
-
-For practical work that means to use the following commands: 
-
-  * create a local branch for `master-news_next`
-
-        $ git fetch
-        $ git checkout -b master-news_next origin/master-news_next
-
-      * if you already have created a local branch `master-news_next`: update to
-        the latest version of it
-
-            $ git checkout master-news_next
-            $ git pull --rebase
-
-  * edit
-
-    Always do check which branch you're on (asterisk in the first column of
-    `git branch`'s output), and only then begin to do your changes and commit
-    them.
-
-    We should not update news items that have already been published (that is,
-    on <http://www.gnu.org/software/hurd/news.html>; no problem for the
-    [[staging area|web_pages#staging_area]]), as the system will always also
-    update the RSS feeds, etc., causing the old news item to reappear on feeds,
-    which is a bit of a nuisance.
-
-      * at the beginning of a month: create a new news entry
-
-            $ cp contributing/web_pages/news/skeleton.mdwn news/YYYY-MM.mdwn
-            $ # edit the new file, then add the changes in git
-            $ git add news/YYYY-MM.mdwn
-            $ git commit -m "Begun the news entry for YYYY-MM."
-
-        That is, use the [[news skeleton|skeleton]] as a template for the new
-        news snippet.  It also includes a list of the places to watch for news.
-
-  * check the outgoing changes
-
-        $ git log --reverse -p -C origin/master-news_next..master-news_next
-
-  * push the changes
-
-        $ git push origin master-news_next
-
-      * if push fails, pull and rebase the local changes on top of the remote
-        changes
-
-            $ git pull --rebase
-
-        This will only happen if someone else has been installing commits into
-        `origin`'s `master-news_next` branch since the last time you
-        synchronized to it.
-
-        Note that this might cause some conflicts to arise -- if the remote
-        repository contains commits that conflict with any that you've been
-        recording in your local repository.  For this reason, you might want to
-        already do this *rebase* before beginning you local edits, simply to
-        shorten the time frame in which such conflicts can arise.
-        (Theoretically, in the very rare case of very much concurrent editing
-        going on, you'd have to repeat this again (and again...) before
-        succeeding to push your changes.)
-
-  * at the end of the month: prepare for publishing the news
+* At the end of the month: prepare for publishing the news
 
     Edit the news entry's *meta date* value to the timestamp when the news
     entry is [[published|news]].  We have to set that one manually, as
     otherwise the timestamp of the news entry file's creation will be taken,
     which is (much) earlier, and not what we want.  We do not set the *meta
     updated* value, as it's correct to update that one upon further
-    modifications of the news entries.
+    modifications of the news entries. 
+
+* Then send it to the mailing list, include all feedback ... 
 
-  * ... and publish
+* ... and publish
 
-        $ git checkout master
-        $ git pull --rebase
-        $ git merge master-news_next
+        $ git cp contributing/web_pages/news/news_moth_next news/yyyy-mm
+        $ git commit -m "Added MotH yyyy-mm"
         $ git push origin master
 
-    That means, for publishing we merge `master-news_next` into `master`.
-    After that merge, work for the next month's news item can continue on
-    `master-news_next`.
+## Information for *writing* the Month of the Hurd
 
-    Arne Babenhauserheide uses a [[merge-news]] script for doing this.
+[[!inline
+pages="contributing/web_pages/news/*"
+show=5
+feeds=no
+actions=yes]]
diff --git a/contributing/web_pages/news/skeleton.mdwn b/contributing/web_pages/news/skeleton.mdwn
index 94fcf738..bf7a980c 100644
--- a/contributing/web_pages/news/skeleton.mdwn
+++ b/contributing/web_pages/news/skeleton.mdwn
@@ -39,44 +39,6 @@ else="
 > 
 > [reason for contibuting to the Hurd]
 
-Watch these places for news:
-
-  * GNU
-
-      * <http://lists.gnu.org/archive/html/bug-hurd/YYYY-MM/threads.html>
-
-      * <http://lists.gnu.org/archive/html/commit-hurd/YYYY-MM/threads.html>
-
-      * <http://lists.gnu.org/archive/html/help-hurd/YYYY-MM/threads.html>
-
-      * <http://lists.gnu.org/archive/html/web-hurd/YYYY-MM/threads.html>
-
-      * <http://lists.gnu.org/archive/html/hurd-devel/YYYY-MM/threads.html>
-
-      * <http://sourceware.org/ml/libc-alpha/YYYY-MM/>
-
-        Also Git log.
-
-      * (<http://sourceware.org/ml/libc-hacker/YYYY-MM/>)
-
-      * (<http://sourceware.org/ml/glibc-cvs/YYYY-qQ/>)
-
-        Better use the Git log.
-
-      * <http://lists.gnu.org/archive/html/l4-hurd/YYYY-MM/threads.html>
-
-  * Debian
-
-      * <http://lists.debian.org/debian-hurd/YYYY/MM/>
-
-      * <http://lists.debian.org/debian-glibc/YYYY/MM/>
-
-  * Arch Hurd
-
-      * <http://www.archhurd.org/news.php>
-
-      * <http://planet.archhurd.org/>
-
-      * (<http://lists.archhurd.org/devel/maillist.html>)
+<!--see [[contributing/web_pages/news/writing_the_moth]] for additional information on writing the MotH.-->
 
 """]]
diff --git a/contributing/web_pages/news/writing-the-moth.mdwn b/contributing/web_pages/news/writing-the-moth.mdwn
index 64f7acdf..56f570b2 100644
--- a/contributing/web_pages/news/writing-the-moth.mdwn
+++ b/contributing/web_pages/news/writing-the-moth.mdwn
@@ -15,3 +15,45 @@ Each news item should show a step towards the mission of the Hurd. From our [[co
 * Attract more developers and/or users.
 
 The reason for this structure is to resolve the problem that many people think that the Hurd won’t ever be finished by concentrating on the improvements and the steps towards completing our mission - but only once they have actually been done (to avoid showing anything which might become vaporware).
+
+### sources for news
+
+Watch these places for news:
+
+  * GNU
+
+      * <http://lists.gnu.org/archive/html/bug-hurd/YYYY-MM/threads.html>
+
+      * <http://lists.gnu.org/archive/html/commit-hurd/YYYY-MM/threads.html>
+
+      * <http://lists.gnu.org/archive/html/help-hurd/YYYY-MM/threads.html>
+
+      * <http://lists.gnu.org/archive/html/web-hurd/YYYY-MM/threads.html>
+
+      * <http://lists.gnu.org/archive/html/hurd-devel/YYYY-MM/threads.html>
+
+      * <http://sourceware.org/ml/libc-alpha/YYYY-MM/>
+
+        Also Git log.
+
+      * (<http://sourceware.org/ml/libc-hacker/YYYY-MM/>)
+
+      * (<http://sourceware.org/ml/glibc-cvs/YYYY-qQ/>)
+
+        Better use the Git log.
+
+      * <http://lists.gnu.org/archive/html/l4-hurd/YYYY-MM/threads.html>
+
+  * Debian
+
+      * <http://lists.debian.org/debian-hurd/YYYY/MM/>
+
+      * <http://lists.debian.org/debian-glibc/YYYY/MM/>
+
+  * Arch Hurd
+
+      * <http://www.archhurd.org/news.php>
+
+      * <http://planet.archhurd.org/>
+
+      * (<http://lists.archhurd.org/devel/maillist.html>)