diff --git a/en/releases/6.1R/Makefile b/en/releases/6.1R/Makefile new file mode 100644 index 0000000000..80b873d688 --- /dev/null +++ b/en/releases/6.1R/Makefile @@ -0,0 +1,24 @@ +# $FreeBSD$ + +.if exists(../Makefile.conf) +.include "../Makefile.conf" +.endif +.if exists(../Makefile.inc) +.include "../Makefile.inc" +.endif + +DOCS= todo.sgml approvals.sgml + +FETCHFILE= http://people.freebsd.org/~pho/stress/log/news.rdf +FETCHCMD= /usr/bin/fetch +CLEANFILES+= news.rdf stress.html + +news.rdf: + ${FETCHCMD} ${FETCHFILE} + +stress.html: news.rdf stress.xsl + ${XSLTPROC} stress.xsl news.rdf > stress.html + +todo.html: stress.html + +.include "${WEB_PREFIX}/share/mk/web.site.mk" diff --git a/en/releases/6.1R/approvals.sgml b/en/releases/6.1R/approvals.sgml new file mode 100644 index 0000000000..bb4233b935 --- /dev/null +++ b/en/releases/6.1R/approvals.sgml @@ -0,0 +1,54 @@ + + + + + + + %navincludes; + %includes; +]> + + +&header; + +

Introduction

+ +

The release engineering team utilizes a code freeze to maintain + stability in the period immediately preceding a release. The + developers below have been given explicit approval by re@ to + continue conservative work in a narrowly defined area until the + expiration dates below. All other developers are required to get + approval for each individual change from re@ before committing to + the release branch.

+ +

General discussions about the release engineering process or + quality assurance issues should be sent to the public freebsd-qa mailing list. + MFC + requests should be sent to re@FreeBSD.org.

+ +

Approval List

+ + + + + + + + +
CommitterAreaExpiration
+ +

Additional Information

+ + + + &footer; + + + diff --git a/en/releases/6.1R/stress.xsl b/en/releases/6.1R/stress.xsl new file mode 100644 index 0000000000..12694ebf8b --- /dev/null +++ b/en/releases/6.1R/stress.xsl @@ -0,0 +1,31 @@ + + + + + + + + + + Generated from XSLT +
    + +
  • + + + + +
    • +     +
+ + + + diff --git a/en/releases/6.1R/todo.sgml b/en/releases/6.1R/todo.sgml new file mode 100644 index 0000000000..c1cde4d630 --- /dev/null +++ b/en/releases/6.1R/todo.sgml @@ -0,0 +1,200 @@ + + + + + + %navincludes; + %includes; + %developers; + +N/A"> +Done"> +In progress"> +Needs testing"> +Not done"> +Unknown"> +Deferred for future release"> + + + + + + +]> + + + + +&header; + +

This is a list of open issues that need to be resolved for FreeBSD + &local.rel;. If you have any updates for this list, please e-mail + re@FreeBSD.org.

+ + + +

Show stopper defects for &local.rel;-RELEASE

+ + + + + + + + + + +
IssueStatusResponsibleDescription
+ +

Required features for &local.rel;-RELEASE

+ + + + + + + + + + +
IssueStatusResponsibleDescription
+ +

Desired features for &local.rel;-RELEASE

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IssueStatusResponsibleDescription
updated hal and ath drivers&status.new;sam
devfs umount panic&status.new; There is a race condition between device removal and devfs + umounts that causes "Memory modified after free" panics. Can + be reproduced by doing 'mdconfig -u' concurrently with unmounting + a devfs instance.
/dev/kmem panic&status.new; Kris has noticed panics on SMP machines when there was ABI + breakage of libkvm and world was not rebuilt and utilities like + fstat were used. This suggests panics can be caused by incorrect + accesses to /dev/kmem.
KLDs on sparc64&status.new; On sparc64 machines with more than 4Gb memory KLDs are not usable + and will panic the system. The problem is reportedly with how the + KLDs are compiled, it only works if the code ends up below 4G.
Max RAM on sparc64&status.new; Maximum RAM on sparc64 appears to be limited to 16Gb.
make -jN&status.new; Doing 'make -jN', then suspending/resuming it may result in make + reporting it lost child process(es).
OpenBSM&status.deferred;&a.rwatson;The integration of OpenBSM is waiting on some final licensing hurdles. + Once those are cleared, it will be a very desirable feature for &local.rel;.
update sysinstall disk labeling&status.wip;&a.rodrigc;Sysinstall could use the same fixes recently made to fdisk so it + plays nice with GEOM and disk labeling. This does not cause problems + during install because nothing on the disk is mounted when its label + is being manipulated but it can cause problems if sysinstall gets + used on a live system to adjust labels on existing disks which + sys-admins tend to do.
+ +

Documentation items that must be resolved for &local.rel;

+ + + + + + + + + + +
IssueStatusResponsibleDescription
+ + +

Testing foci for &local.rel;-RELEASE

+ + + + + + + + + + +
IssueStatusResponsibleDescription
+ +

Stress Test Panics

+ + +

The system is continuously being subjected to Peter Holm's Kernel Stress Test Suite. The + following issues have recently been discovered from this test + suite.

+ +&stresstest; + + &footer; + + +