summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--community/weblogs/ArneBab/howto-news-month-of-the-hurd.mdwn54
-rw-r--r--contributing/web_pages.mdwn6
-rw-r--r--contributing/web_pages/news.mdwn99
3 files changed, 105 insertions, 54 deletions
diff --git a/community/weblogs/ArneBab/howto-news-month-of-the-hurd.mdwn b/community/weblogs/ArneBab/howto-news-month-of-the-hurd.mdwn
deleted file mode 100644
index f365bc79..00000000
--- a/community/weblogs/ArneBab/howto-news-month-of-the-hurd.mdwn
+++ /dev/null
@@ -1,54 +0,0 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!meta title="HowTo prepare and publish 'a month of the Hurd' for the next month"]]
-
-We prepare the month of the Hurd in a public git branch (master-news_next) and merge it once we want to publish the news.
-
-For practical work that means, we use the following commands:
-
-* create a local branch for news_next
-
- git fetch && git checkout -b master-news_next origin/master-news_next
-
-* get the latest version of news_next when you already created a local version of the branch
-
- git fetch && git checkout master-news_next
-
-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.
-
-* create a new news entry
-
- cp news/yyyy-mm-dd.mdwn news/YYYY-MM-DD.mdwn
- (edit the new file)
- git add news/YYYY-MM-DD.mdwn
- git commit -m "Begun the news entry for YYYY-MM-DD."
-
-(just copy the most recent news file)
-
-* 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:master-news_next
-
-* if push fails, pull and rebase
-
- git pull --rebase
-
-* publish the news
-
- git checkout master && git merge master-news_next
-
-That means, for publishing we merge master-news_next into master.
diff --git a/contributing/web_pages.mdwn b/contributing/web_pages.mdwn
index f1388bc2..e01a0040 100644
--- a/contributing/web_pages.mdwn
+++ b/contributing/web_pages.mdwn
@@ -48,7 +48,13 @@ we do have some simple requests. Please try to match the *tone* of your topics
and edits with the existing topics. If we all pull in the same direction these
pages will be more useful for everyone, especially for our own use.
+### News Items
+
+There are [[more detailed instructions about editing news items|news]].
+
+<a name="staging_area">
## Staging Area
+</a>
When you commit changes, either using the web interface or checking them in
into the repository, they'll not become visible on
diff --git a/contributing/web_pages/news.mdwn b/contributing/web_pages/news.mdwn
new file mode 100644
index 00000000..d6e25b87
--- /dev/null
+++ b/contributing/web_pages/news.mdwn
@@ -0,0 +1,99 @@
+[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled [[GNU Free Documentation
+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
+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 news/2009-06-30.mdwn news/YYYY-MM-DD.mdwn
+ $ # edit the new file
+ $ git add news/YYYY-MM-DD.mdwn
+ $ git commit -m "Begun the news entry for YYYY-MM-DD."
+
+ That is, use the *2009-06-30* news snippet as a template for the new
+ one.
+
+ * 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: publish the news
+
+ $ git checkout master
+ $ git pull --rebase
+ $ git merge master-news_next
+ $ 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`.