Remove //net (except for Android test stuff) and sdch

net/docs/bug-triage-suggested-workflow.txt

-Identifying unlabeled network bugs on the tracker:
-* Look at new uncomfirmed bugs since noon PST on the last triager's rotation:
-    https://code.google.com/p/chromium/issues/list?can=2&q=status%3Aunconfirmed&sort=-id&num=1000
-* Press "h" to bring up a preview of the bug text.
-* Use "j" and "k" to advance through bugs.
-* If a bug looks like it might be network/download/safe-browsing related, middle
-    click [or command-click on OSX] to open in new tab.
-* If a user provides a crash ID for a crasher for a bug that could be
-    net-related, look at the crash stack at go/crash, and see if it looks to be
-    network related.  Be sure to check if other bug reports have that stack
-    trace, and mark as a dupe if so.  Even if the bug isn't network related,
-    paste the stack trace in the bug, so no one else has to look up the crash
-    stack from the ID.
-  * If there's no other information than the crash ID, ask for more details and
-      add the Needs-Feedback label.
-* If network causes are possible, ask for a net-internals log (If it's not a
-    browser crash) and attach the most specific internals-network label that's
-    applicable.  If there isn't an applicable narrower label, a clear owner for
-    the issue, or there are multiple possibilities, attach the internals-network
-    label and proceed with further investigation.
-* If non-network causes also seem possible, attach those labels as well.
-
-Investigating Cr-Internals-Network bugs:
-* It's recommended that while on triage duty, you subscribe to the
-    Cr-Internals-Network label.  To do this, go to
-    https://code.google.com/p/chromium/issues/ and click on "Subscriptions".
-    Enter Cr-Internals-Network and click submit.
-* Look through uncomfirmed and untriaged Cr-Internals-Network bugs, prioritizing
-    those updated within the last week:
-    https://code.google.com/p/chromium/issues/list?can=2&q=Cr%3DInternals-Network+-status%3AAssigned+-status%3AStarted+-status%3AAvailable+&sort=-modified
-* While investigating a new issue, change the status to Untriaged.
-* If a bug is a potential security issue (Allows for code execution from remote
-    site, allows crossing security boundaries, unchecked array bounds, etc) mark
-    it Type-Bug-Security.  If it has privacy implication (History, cookies
-    discoverable by an entity that shouldn't be able to do so, incognito state
-    being saved in memory or on disk beyond the lifetime of incognito tabs,
-    etc), mark it Cr-Privacy.
-* For bugs that already have a more specific network label, go ahead and remove
-    the Cr-Internals-Network label and move on.
-* Try to figure out if it's really a network bug.  See common non-network labels
-    section for description of common labels needed for issues incorrectly
-    tagged as Cr-Internals-Network.
-* If it's not, attach appropriate labels and go no further.
-* If it may be a network bug, attach additional possibly relevant labels if any,
-    and continue investigating.  Once you either determine it's a non-network
-    bug, or figure out accurate more specific network labels, your job is done,
-    though you should still ask for a net-internals dump if it seems likely to
-    be useful.
-* Note that ChromeOS-specific network-related code (Captive portal detection,
-    connectivity detection, login, etc) may not all have appropriate more
-    specific labels, but are not in areas handled by the network stack team.
-    Just make sure those have the OS-Chrome label, and any more specific labels
-    if applicable, and then move on.
-* Gather data and investigate.
-  * Remember to add the Needs-Feedback label whenever waiting for the user to
-      respond with more information, and remove it when not waiting on the user.
-  * Try to reproduce locally.  If you can, and it's a regression, use
-      src/tools/bisect-builds.py to figure out when it regressed.
-  * Ask more data from the user as needed (net-internals dumps, repro case,
-      crash ID from about:crashes, run tests, etc).
-  * If asking for an about:net-internals dump, provide this link:
-      https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details.
-      Can just grab the link from about:net-internals, as needed.
-* Try to figure out what's going on, and which more specific network label is
-    most appropriate.
-* If it's a regression, browse through the git history of relevant files to try
-    and figure out when it regressed.  CC authors / primary reviewers of any
-    strongly suspect CLs.
-* If you are having trouble with an issue, particularly for help understanding
-    net-internals logs, email the public net-dev@chromium.org list for help
-    debugging.  If it's a crasher, or for some other reason discussion needs to
-    be done in private, use chrome-network-debugging@google.com.
-    TODO(mmenke): Write up a net-internals tips and tricks docs.
-* If it appears to be a bug in the unowned core of the network stack (i.e. no
-    sublabel applies, or only the Cr-Internals-Network-HTTP sublabel applies,
-    and there's no clear owner), try to figure out the exact cause.
-
-Look for new crashers:
-* Go to go/chromecrash.
-* For each platform, go to the latest canary.
-* In the "Process Type" frame, click on "browser".
-* At the bottom of the "Magic Signature" frame,  click "limit 1000".
-  Reported crashers are sorted in decreasing order of the number of reports for
-  that crash signature.
-* Search the page for "net::".  Ignore crashes that only occur once, as
-    memory corruption can easily cause one-off failures when the sample size is
-    large enough.
-* Click on the number of reports field to see details of crash. Look at the
-    stack trace to confirm it's a network bug.
-  * If it is, and there's no associated bug filed, file a new bug directly from
-      chromecrash, looking at earlier canaries to determine if it's a recent
-      regression.  Use the most specific label possible.
-* The most recent Canary may not yet have a full day of crashes, so it may be
-    worth looking at more than one version.
-* If there's been a dev, beta, or stable release in the last couple days, should
-    also look at those.
-
-Investigating crashers:
-* Only investigate crashers that are still occurring, as identified by above
-    section.  If a search on go/crash indicates a crasher is no longer
-    occurring, mark it as WontFix.
-* Particularly for Windows, look for weird dlls associated with the crashes.
-    If there are some, it may be caused by malware.  You can often figure out if
-    a dll is malware by a search, though it's harder to figure out if a dll is
-    definitively not malware.
-* See if the same users are repeatedly running into the same issue.  This can be
-    accomplished by search for (Or clicking on) the client ID associated with a
-    crash report, and seeing if there are multiple reports for the same crash.
-    If this is the case, it may be also be malware, or an issue with an unusual
-    system/chrome/network config.
-* Dig through crash reports to figure out when the crash first appeared, and dig
-    through revision history in related files to try and locate a suspect CL.
-    TODO(mmenke):  Add more detail here.
-* Load crash dumps, try to figure out a cause.
-    See http://www.chromium.org/developers/crash-reports for more information
-
-Dealing with old bugs:
-* For all network issues (Even those with owners, or a more specific labels):
-  * If the issue has had the Needs-Feedback label for over a month, verify it
-      is waiting on feedback from the user.  If not, remove the label.
-      Otherwise, go ahead and mark the issue WontFix due to lack of response and
-      suggest the user file a new bug if the issue is still present.
-      Old Needs-Feedback issues:  https://code.google.com/p/chromium/issues/list?can=2&q=Cr%3AInternals-Network%20Needs=Feedback+modified-before%3Atoday-30&sort=-modified
-  * If a bug is over 2 months old, and the underlying problem was never
-    reproduced or really understood:
-    * If it's over a year old, go ahead and mark the issue as Archived.
-    * Otherwise, ask reporters if the issue is still present, and attach the
-        Needs-Feedback label.
-* Old unconfirmed or untriaged Cr-Internals-Network issues can be investigated
-    just like newer ones.  Crashers should generally be given higher priority,
-    since we can verify if they still occur, and then newer issues, as they're
-    more likely to still be present, and more likely to have a still responsive
-    bug reporter.