* Name of the new feature/description of the change, including a small explanation (if possible). Add links to web pages (if available), papers, etc. Keep the structure of previous changelogs!
 * If there's a interesting email (benchmarks, announcements if there's no web page, etc) about it in the mailing lists, get a link in one of the list's archives (at http://marc.theaimsgroup.com/?l=linux-kernel please, just for coherence. There're also fsdev & netdev mailing lists, etc) and add it.
 * Add commit's link to the git's web interface if possible, using the "(commit)" word.
 * To find commit's links you can search in the [[http://www.kernel.org/git|git web interface]]. Remember that there're two main GIT trees where you can search for commits: [[http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git|the one which has all the stuff committed after 2.6.12-rc2]] (ie: current development) and [[http://kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git|the one which has all the stuff BEFORE 2.6.12-rc2]]
 * However, if you want to keep track in "realtime", do NOT use the git's web interface (or the RSS). The RSS gets overflowed when there's a big merge. And more importantly, the shortlog you find in git's web interface does NOT care when things were really "committed": If a developer writes a patch, merges it in his git repository and then Linus pulls and merges it a month after it was merged in the developer's repository , the commit data won't appear in the "todays shortlog", but in the one-month-old changes (this could be fixed in the future however). 
 * IOW: To keep track of the linux merges in realtime, the best option is to [[http://vger.kernel.org/vger-lists.html#git-commits-head|subscribe to the git-commits-head]] mailing list (or search in the archives). Commit IDs are in the X-Git-Commit mail header. Tell your mailer to show them (by default it will be hidden unless you activate the "see the whole mail" option), if your mailer is good enought you'll be able to add a script which gets the Commit ID out of the header and launch a browser with the "http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=" needed gitweb URL before it.
 * It may look too hard to review the thousands of emails you get from the git-commit-head list, get the commit ID, the URL, a description and format all of it to put it here: "Formatting" is what would take most of your time. But the fact is that you can avoid most of the hard job by using some tricks. First of all, most of the relevant commits will be merged (and sent to the git-commits-head list) in the first two weeks after a kernel is released. When the mailing list sends you the commit messages, use the "mark" feature of your mailer to mark important commits - this is a easy operation, since the subject tells you if the commit is important, you can review quite a lot of commit messages per minute. When you're done, create an action/filter/whatever which allows you to extract the commit id. My MUA (sylpheed) allows me to create an "action" which allows me to pass the selected message(s) to a command. This allows to me to order my messages by marked/umarked to make easier to select at the same time all the marked messages, the I tell sylpheed to execute the previous "action", which runs a scripts which "greps" the commit-id out of the email headers and appends it to a file. This way I get a file with a list of all the relevant commit IDs (Other MUAS could have another methods to achieve this same goal or not have any at all). Now, with a local linux git repository (updated to head) and with a bit of scripting you can get (with git) the changelog information of every commit ID, so you can parse that information and generate a wiki-compatible-syntax list of commits with descriptions, URLs to gitweb automatically generated, etc. You'll need to fix the descriptions, but you get a LOT of work done automatically.
 * The web interface will show "meta-commits". When Linus merges things from a remote repository, You'll see a "Merge git://git.domain.com/foo/bar" style of message commit. If you click it for details you'll see a huge merge, but then the git shortlog will also show the individual commits. So those "meta-commits" are useful to add links to big merges which do one thing but do not mean anything by themselves. Those "meta-commits" will not be mailed to the git-commits-head mailing list.

Random related stuff:

 * [[http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc5/2.6.14-rc5-mm1/broken-out/post-halloween-doc.patch|davej's post halloween document]], [[http://kernelnewbies.org/status/latest.html|Kernelnewbies status]]
 * Todo: Find links to corresponding changesets for the untracked 2.5 releases (if you're really bored)