diff --git a/en/releases/4.5R/Makefile b/en/releases/4.5R/Makefile
new file mode 100644
index 0000000000..b0eeef36fb
--- /dev/null
+++ b/en/releases/4.5R/Makefile
@@ -0,0 +1,12 @@
+# $FreeBSD$
+
+.if exists(../Makefile.conf)
+.include "../Makefile.conf"
+.endif
+.if exists(../Makefile.inc)
+.include "../Makefile.inc"
+.endif
+
+DOCS= qa.sgml
+
+.include "${WEB_PREFIX}/share/mk/web.site.mk"
diff --git a/en/releases/4.5R/qa.sgml b/en/releases/4.5R/qa.sgml
new file mode 100644
index 0000000000..4c825366b3
--- /dev/null
+++ b/en/releases/4.5R/qa.sgml
@@ -0,0 +1,91 @@
+
+
+
+
+ %includes;
+]>
+
+&header;
+
+As part of our on-going effort to improve the release engineering
+ process, we have identified several areas that need significant
+ quality assurance testing during the release candidate phase.
+ Below, we've listed the changes in 4.5-PRERELEASE that we feel merit
+ the most attention due to their involving substantial changes to the
+ system, or having arrived late in the development cycle leading up
+ to the release. In general, our goal in the QA process is to
+ attempt to check a number of things:
+
+
+ - The system has not regressed with respects to stability, correctness,
+ interoperability, or performance of features present in prior
+ releases.
+
+ - New features result in the desired improvement in stability,
+ correctness, interoperability, or performance.
+
+
+To effectively determine this, it's desirable to test the system in
+ a diverse set of environments, applying a wide set of workloads,
+ forcing the system to operate both within and outside its normal
+ specification. Particular focus should often be placed on the
+ continuing (or new) capability of the system to perform correctly
+ when used in concert with systems from other vendors.
+
+Features to explore carefully:
+
+
+
+ - Recent TCP changes, especially relating to the delayed ACK fix,
+ congestion response, syncache, syncookies, increased socket buffer
+ sizes, et al. We're interested in testing interoperability with
+ as many platforms as possible, demonstrating continued strong (and
+ better) scalability and performance, and watching out for quirks
+ (connection stalls, ...), not to mention crashes. Jonathan Lemon
+ was responding to a panic report on freebsd-current earlier today
+ regarding a PCB call, which is something we should keep an eye on.
+ On the other hand, Yahoo! is
+ now deploying this code, and that should help test it a great
+ deal.
+
+ - VFS/VM/NFS fixes. We need to continue to test performance,
+ correctness, and interoperability. In particular, I'd like to see
+ a lot of inter-platform performance testing (FreeBSD->Solaris,
+ vice versa, etc). We'd also like careful investigation of
+ low-memory situations.
+
+ - FFS fixes. We had some reports of deadlocks in FFS; it sounds like
+ Matt Dillon has caught most of them, but combinations I'd particular
+ like to see tested involve Quotas, Chroot, and NFS, under load, and
+ involving memory mapping and heavy directory operations.
+
+ - NTP 4.1. This is probably reasonable safe, but it doesn't hurt
+ to do interop testing, especially on the Alpha platform.
+
+ - SMBfs. We need stability testing, mostly, I suspect. Performance is
+ probably not a large focus. While SMBfs support has been available on
+ -STABLE through a port previously, determining that the integration
+ with the base system (especially the boot process) was done correctly
+ is important. Attempting to use SMBfs in /etc/fstab in a diskless
+ environment might be one thing to explore, for example.
+
+ - Once the man page change goes in (which I think it should) we'll want
+ some basic testing of the man command.
+
+ - cdboot. Late in the release cycle, a new implementation of the
+ CD-based boot loader was introduced. This should generally
+ improve support for booting or installing from CD, but this change
+ requires testing on a variety of architectures and devices.
+
+
+
+The release notes will always be a good place to look for things to
+ test. There are a number of new drivers, including if_em, which
+ would probably benefit from more exposure. Please report bugs to
+ the qa@FreeBSD.org list, and/or
+ via send-pr with a heads up to the qa list.
+
+&footer;
+
+