os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Define and use some entities for CVS branch names.

Browse source
This commit is contained in:
Bruce A. Mah 2003-02-17 22:37:42 +00:00
parent 5c968def66
commit ff1fde8ecf
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=16049
1 changed files with 48 additions and 42 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

90
en_US.ISO8859-1/articles/5-roadmap/article.sgml
View file

@ -14,6 +14,12 @@
<!ENTITY % mailing-lists PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//EN">
%mailing-lists;
<!ENTITY t.releng.4 "<literal>RELENG_4</literal>">
<!ENTITY t.releng.5 "<literal>RELENG_5</literal>">
<!ENTITY t.releng.5.1 "<literal>RELENG_5_1</literal>">
<!ENTITY t.releng.5.2 "<literal>RELENG_5_2</literal>">
<!ENTITY t.releng.head "<literal>HEAD</literal>">
]>
<article>
@ -54,20 +60,20 @@
clean up later. This decision resulted in the 3.0 and 3.1 releases
being very unsatisfying for most, and it wasn't until 3.2 that the
series was considered <quote>stable</quote>. To make matters worse, the RELENG_3
branch was created along with the 3.0 release, and the HEAD branch was
branch was created along with the 3.0 release, and the &t.releng.head; branch was
allowed to advance immediately towards 4-CURRENT. This resulted in a
quick divergence between HEAD and RELENG_3, making maintenance of the
quick divergence between &t.releng.head; and RELENG_3, making maintenance of the
RELENG_3 branch very difficult. &os; 2.2.8 was left for quite a while
as the last production-quality version of &os;.</para>
<para>Our intent is to avoid repeating that scenario with &os; 5.x.
Delaying the RELENG_5 branch until it is stable and production quality
Delaying the &t.releng.5; branch until it is stable and production quality
will ensure that it stays maintainable and provides a compelling reason
to upgrade from 4.<replaceable>X</replaceable>, To do this, we must
identify the current areas of weakness and set clear goals for
resolving them. This document contains what we as the release
engineering team feel are the milestones and issues that must be
resolved for the RELENG_5 branch. It does not dictate every aspect of
resolved for the &t.releng.5; branch. It does not dictate every aspect of
&os; development, and we welcome further input. Nothing that follows
is meant to be a sleight against any person or group, or to trivialize
any work that has been done. There are some significant issues,
@ -186,7 +192,7 @@
will also help this, as will converting drivers to be as efficient as
possible in their interrupt routines.</para>
<para>Next, the state of KSE must resolved for RELENG_5. Work on it has
<para>Next, the state of KSE must resolved for &t.releng.5;. Work on it has
slowed noticeably in the past 6 months but appears to be picking up
again. There are a number of issues that must be addressed:</para>
@ -206,11 +212,11 @@
<para>According to the release schedule below, KSE kernel and userland
components must be functionality complete by June 2003 in order to be
included in the RELENG_5 branch. For security and stability reasons,
included in the &t.releng.5; branch. For security and stability reasons,
if KSE cannot be finished in time then, by default, all KSE-specific
syscalls should be modified to return ENOSYS and all other KSE-specific
interfaces disabled. Deprecating KSE from RELENG_5 but keeping it in
the HEAD branch will pose problems in porting bugfixes and features
interfaces disabled. Deprecating KSE from &t.releng.5; but keeping it in
the &t.releng.head; branch will pose problems in porting bugfixes and features
between the two branches, so every effort should be made to finish it
on time.</para>
</sect1>
@ -218,7 +224,7 @@
<sect1 id="goals">
<title>Goals for 5-STABLE</title>
<para>The goals for the RELENG_5 branch point are:</para>
<para>The goals for the &t.releng.5; branch point are:</para>
<itemizedlist>
<listitem>
@ -241,13 +247,13 @@
Both UP and SMP configurations should be evaluated. SMP has the
potential to perform much better than
4.<replaceable>X</replaceable>, though for the purposes of creating
the RELENG_5 branch, comparable performance between the two should
the &t.releng.5; branch, comparable performance between the two should
be acceptable.</para>
</listitem>
</itemizedlist>
<para>It is unrealistic to expect that the SMPng project will be fully
complete by RELENG_5, or that performance will be significantly better
complete by &t.releng.5;, or that performance will be significantly better
than 4.<replaceable>X</replaceable>. However, focusing on a subset of
the outstanding tasks will give enough benefit for the branch to be
viable and maintainable. To break it down:</para>
@ -255,8 +261,8 @@
<itemizedlist>
<listitem>
<para>ABI/API/Infrastructure stability - Enough infrastructure must
be in place and stable to allow fixes from HEAD to easily and
safely be merged into RELENG_5. Also, we must draw a line as to
be in place and stable to allow fixes from &t.releng.head; to easily and
safely be merged into &t.releng.5;. Also, we must draw a line as to
what subsystems are to be locked down when we go into
5-STABLE.</para>
@ -267,7 +273,7 @@
<itemizedlist>
<listitem>
<para>VM: Most codepaths, others than the ones that interact with
VFS, should be Giant-free for RELENG_5.</para>
VFS, should be Giant-free for &t.releng.5;.</para>
</listitem>
<listitem>
@ -275,10 +281,10 @@
the risk of uncovering latent bugs and races. Locking it down
but not removing Giant imposes further performance penalties. A
decision on which parts of the network stack should be locked and
taken out from under Giant for RELENG_5 should be made no later
taken out from under Giant for &t.releng.5; should be made no later
than March 15. Work on the IP, TCP, UDP,raw IP, routing sockets,
and Unix domain sockets stands a good chance of being complete in
time for RELENG_5.</para>
time for &t.releng.5;.</para>
<para>If the decision is made to not lift Giant from the stack,
then the locks in these layers could be optimized out with a
@ -324,7 +330,7 @@
demonstrate a real-world application running correctly on it using
the standard POSIX Threads API. Examples would be apache 2.0,
Java, and/or mozilla. A functional regression test suite is also a
requirement for RELENG_5 and should test signal delivery,
requirement for &t.releng.5; and should test signal delivery,
scheduling, performance, and process security/credentials for both
KSE and non-KSE processes. KSE kernel and userland components must
also reach the same level of functionality for all Tier-1 platforms
@ -343,10 +349,10 @@
<ulink url="http://www.FreeBSD.org/projects/busdma">
http://www.FreeBSD.org/projects/busdma</ulink> tracks the
progress of this and should be used to determine which drivers
must be converted for RELENG_5 and which can be left behind.
must be converted for &t.releng.5; and which can be left behind.
Also, there has been talk by several developers and the original
author to give the busdma interface a minor overhaul. If this is
to happen, it needs to happen before RELENG_5. Otherwise,
to happen, it needs to happen before &t.releng.5;. Otherwise,
differences between the old and new API will make driver
maintenance difficult.</para>
</listitem>
@ -358,8 +364,8 @@
manage and allocate PCI memory resources on its own. Implementing
this should take into account cardbus, PCI-HotPlug, and laptop
dockstation requirements. This feature will become increasingly
critical through the lifetime of RELENG_5, and therefore is a
requirement for the RELENG_5 branch.</para>
critical through the lifetime of &t.releng.5;, and therefore is a
requirement for the &t.releng.5; branch.</para>
</listitem>
</itemizedlist>
</listitem>
@ -485,7 +491,7 @@
problems on some laptops. The classic 16-bit bridge support,
OLDCARD, still exists and can be compiled in, but this is highly
inconvenient for users of older laptops. If OLDCARD cannot be
completely deprecated for RELENG_5, then provisions must be made
completely deprecated for &t.releng.5;, then provisions must be made
to allow users to easily install an OLDCARD-enabled kernel.
Documentation should be written to help trasition users from
OLDCARD to NEWCARD and from &man.pccardd.8; to
@ -503,7 +509,7 @@
and the new ULE scheduler. A scheduler that demonstrates
processor affinity, HyperThreading and KSE awareness, and no
regressions in performance or interactivity characteristics must
be available for RELENG_5.</para>
be available for &t.releng.5;.</para>
</listitem>
<listitem>
@ -512,27 +518,27 @@
console support. This is a major support hole for what is a
Tier 1 platform. Whether syscons can be shoe-horned in or
wscons be adopted from NetBSD is up for debate. However,
sparc64 must have local console support for RELENG_5. Having
sparc64 must have local console support for &t.releng.5;. Having
this will also enable the XFree86 server to run, which is also a
requirement for RELENG_5.</para>
requirement for &t.releng.5;.</para>
</listitem>
<listitem>
<para>gcc/toolchain: gcc 3.3 might be available in time for
RELENG_5 and might offer some attractive benefits, but also
&t.releng.5; and might offer some attractive benefits, but also
likely to introduce ABI incompatibility with prior gcc versions.
ABI compatibility should be locked down for the RELENG_5
ABI compatibility should be locked down for the &t.releng.5;
branch.</para>
<para>There has also been a request to move /usr/include/g++ to
/usr/include/g++-v3 to be more compliant with the stock behavior
of gcc. This should also be investigated for RELENG_5.</para>
of gcc. This should also be investigated for &t.releng.5;.</para>
</listitem>
<listitem>
<para>gdb: gdb from the base system should work for sparc64. It
should also understand KSE thread semantics, assuming that KSE
is included in the RELENG_5 branch. gdb 5.3 is available and
is included in the &t.releng.5; branch. gdb 5.3 is available and
there are reports that it should address the sparc64 issue.</para>
</listitem>
@ -566,9 +572,9 @@
</listitem>
<listitem>
<para>If &os; 5.1 is not the branch point for RELENG_5 then the
<para>If &os; 5.1 is not the branch point for &t.releng.5; then the
Early Adopters Guide needs to be updated. This document should
then be removed just before the release closest to the RELENG_5
then be removed just before the release closest to the &t.releng.5;
branch point.</para>
</listitem>
</itemizedlist>
@ -579,7 +585,7 @@
<sect1 id="schedule">
<title>Schedule</title>
<para>If branching RELENG_5 at the 5.1 release is paramount, 5.1 will
<para>If branching &t.releng.5; at the 5.1 release is paramount, 5.1 will
probably need to move out by at least 3 months. The schedule would
be:</para>
@ -591,7 +597,7 @@
<para>Aug 4, 2003: 5.1-BETA, general code freeze</para>
</listitem>
<listitem>
<para>Aug 18, 2003: 5.1-RC1, RELENG_5 and RELENG_5_1 branched</para>
<para>Aug 18, 2003: 5.1-RC1, &t.releng.5; and &t.releng.5.1; branched</para>
</listitem>
<listitem>
<para>Aug 25, 2003: 5.1-RC2</para>
@ -617,7 +623,7 @@
<para>May 5, 2003: 5.1-BETA, general code freeze</para>
</listitem>
<listitem>
<para>May 19, 2003: 5.1-RC1, RELENG_5_1 branched</para>
<para>May 19, 2003: 5.1-RC1, &t.releng.5.1; branched</para>
</listitem>
<listitem>
<para>May 27, 2003: 5.1-RC2</para>
@ -632,7 +638,7 @@
<para>Sept 1, 2003: 5.2-BETA, general code freeze</para>
</listitem>
<listitem>
<para>Sept 15, 2003: 5.2-RC1, RELENG_5 and RELENG_5_2 branched</para>
<para>Sept 15, 2003: 5.2-RC1, &t.releng.5; and &t.releng.5.2; branched</para>
</listitem>
<listitem>
<para>Sept 22, 2003: 5.2-RC2</para>
@ -644,20 +650,20 @@
</sect1>
<sect1 id="future">
<title>Post RELENG_5 direction</title>
<title>Post &t.releng.5; direction</title>
<para> As with all -STABLE development streams, the focus should be bug
fixes and incremental improvements. Just like normal, everything
should be vetted through the HEAD branch first and committed to
RELENG_5 with caution. As before, new device drivers, incremental
should be vetted through the &t.releng.head; branch first and committed to
&t.releng.5; with caution. As before, new device drivers, incremental
features, etc, will be welcome in the branch once they have been proven
in HEAD.</para>
in &t.releng.head;.</para>
<para>Further SMPng lockdowns will be divided into two categories, driver
and subsystem. The only subsystem that will be sufficiently locked
down for RELENG_5 will be GEOM, so incrementally locking down device
down for &t.releng.5; will be GEOM, so incrementally locking down device
drivers under it is a worthy goal for the branch. Full subsystem
lockdowns will have to be fully tested and proven in HEAD before
consideration will be given to merging them into RELENG_5.</para>
lockdowns will have to be fully tested and proven in &t.releng.head; before
consideration will be given to merging them into &t.releng.5;.</para>
</sect1>
</article>