WIP: Migrate Wiki content over to src/docs

docs/stability_fixit_week.md

Index: docs/stability_fixit_week.md
diff --git a/docs/stability_fixit_week.md b/docs/stability_fixit_week.md
new file mode 100644
index 0000000000000000000000000000000000000000..d6ace66074974343f40a7100c68fb6a888799d9c
--- /dev/null
+++ b/docs/stability_fixit_week.md
@@ -0,0 +1,62 @@
+# Stability Fixit Week
+
+The Chromium project tries hard to avoid bugs.
+We close the tree if even a tiny bug is detected by our continuous test suite.
+For bugs that can't be fixed right away, we file bug reports so developers can fix them offline.
+But after a while, the stack of crash and leak bug reports can be overwhelming
+for a single engineer to attack.  So every now and then, we hold
+Stability Fixit Weeks so we can gang up on those bugs, and
+make some headway on the pile.
+
+We're especially interested in bugs taged with Fixit and Valgrind (click for lists):
+  * [Valgrind+Fixit](http://crbug.com/?can=2&q=label:Valgrind+Fixit&sort=-id)
+
+but any of the following could also use attention:
+  * [Valgrind](http://crbug.com/?can=2&q=label:Valgrind&sort=-id)
+  * [Crash](http://crbug.com/?can=2&q=label:crash&sort=-id)
+  * [Regression](http://crbug.com/?can=2&q=label:regression&sort=-id)
+  * [Fixit](http://crbug.com/?can=2&q=label:fixit&sort=-id)
+  * [LinuxBeta](http://crbug.com/?can=2&q=label:Mstone-LinuxBeta&sort=-id)
+  * [MacBeta](http://crbug.com/?can=2&q=label:Mstone-MacBeta&sort=-id)
+
+Memory leaks aren't as high priority as other sorts of Valgrind errors, but they're still worth fixing.
+
+To work on Valgrind bugs, it helps to have the tool installed.
+
+Valgrind **is** free; see http://dev.chromium.org/developers/how-tos/using-valgrind for how to install and use it with Chrome on Mac and Linux.
+
+The bug reports usually name the test that exposed the problem; to
+reproduce the problem, you have to run the same test under Valgrind.
+That can be slow, and these bugs are subtle, so while you're waiting, try to understand the bug by inspection of the source code.
+
+If the bug in question is already being suppressed, you may need to remove the suppression before you can see it.
+With Valgrind, it's easy to find and comment out suppressions; they're mostly in tools/valgrind/memcheck/suppressions.txt, and every suppression has an associated bug number.  (Mac-specific suppressions are in a nearby file, suppressions\_mac.txt.)
+
+To try to reproduce a problem in a UI test named Foo.Bar with Valgrind, give the command
+```
+tools/valgrind/chrome_tests.sh -t ui --gtest_filter=Foo.Bar
+```
+
+(Generally you should be in the chromium/src directory to run any of these tests.)
+
+Layout tests are a bit different.
+
+To try to reproduce a problem in a test named LayoutTests/fast/loader/local-css-from-local-html.html with Valgrind, you would give the command
+```
+tools/valgrind/valgrind_webkit_tests.sh LayoutTests/fast/loader/local-css-from-local-html.html
+```
+This will eventually produce output on stdout, but rather than wait, you can look in the current directory for its temporary log files while it's still producing them.
+
+Sometimes problems only happen occasionally; you might want to write a little script to run your test in a loop.  Or you might run a wide overnight fishing expedition to see if you can find any valgrind errors
+at all in one area of the tests.
+
+Note that the only kind of leak reports we care about from Valgrind are those marked "definitely leaked".  Ones marked "possibly leaked" should usually be ignored.
+
+## See Also
+
+  * StabilizeTrunk
+  * LayoutTestsLinux
+  * LinuxDebugging
+  * [RunningChromeUITests](RunningChromeUITests.md)
+  * http://dev.chromium.org/developers/how-tos/using-valgrind
+  * http://dev.chromium.org/developers/testing