diff --git a/en_US.ISO8859-1/articles/5-roadmap/article.sgml b/en_US.ISO8859-1/articles/5-roadmap/article.sgml index eaff4efcaf..6919d9c07c 100644 --- a/en_US.ISO8859-1/articles/5-roadmap/article.sgml +++ b/en_US.ISO8859-1/articles/5-roadmap/article.sgml @@ -14,6 +14,12 @@ %mailing-lists; +RELENG_4"> +RELENG_5"> +RELENG_5_1"> +RELENG_5_2"> +HEAD"> + ]>
@@ -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 stable. 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;. 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.X, 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. - Next, the state of KSE must resolved for RELENG_5. Work on it has + 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: @@ -206,11 +212,11 @@ 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. @@ -218,7 +224,7 @@ Goals for 5-STABLE - The goals for the RELENG_5 branch point are: + The goals for the &t.releng.5; branch point are: @@ -241,13 +247,13 @@ Both UP and SMP configurations should be evaluated. SMP has the potential to perform much better than 4.X, 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. 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.X. 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: @@ -255,8 +261,8 @@ 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. @@ -267,7 +273,7 @@ VM: Most codepaths, others than the ones that interact with - VFS, should be Giant-free for RELENG_5. + VFS, should be Giant-free for &t.releng.5;. @@ -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. + time for &t.releng.5;. 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 @@ http://www.FreeBSD.org/projects/busdma 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. @@ -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. + critical through the lifetime of &t.releng.5;, and therefore is a + requirement for the &t.releng.5; branch. @@ -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. + be available for &t.releng.5;. @@ -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. + requirement for &t.releng.5;. 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. 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. + of gcc. This should also be investigated for &t.releng.5;. 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. @@ -566,9 +572,9 @@ - If &os; 5.1 is not the branch point for RELENG_5 then the + 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. @@ -579,7 +585,7 @@ Schedule - If branching RELENG_5 at the 5.1 release is paramount, 5.1 will + 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: @@ -591,7 +597,7 @@ Aug 4, 2003: 5.1-BETA, general code freeze - Aug 18, 2003: 5.1-RC1, RELENG_5 and RELENG_5_1 branched + Aug 18, 2003: 5.1-RC1, &t.releng.5; and &t.releng.5.1; branched Aug 25, 2003: 5.1-RC2 @@ -617,7 +623,7 @@ May 5, 2003: 5.1-BETA, general code freeze - May 19, 2003: 5.1-RC1, RELENG_5_1 branched + May 19, 2003: 5.1-RC1, &t.releng.5.1; branched May 27, 2003: 5.1-RC2 @@ -632,7 +638,7 @@ Sept 1, 2003: 5.2-BETA, general code freeze - Sept 15, 2003: 5.2-RC1, RELENG_5 and RELENG_5_2 branched + Sept 15, 2003: 5.2-RC1, &t.releng.5; and &t.releng.5.2; branched Sept 22, 2003: 5.2-RC2 @@ -644,20 +650,20 @@ - Post RELENG_5 direction + Post &t.releng.5; direction 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. + in &t.releng.head;. 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. + 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;.