share/doc/papers/relengr/2.t

   1 .\"     $NetBSD: 2.t,v 1.2 1998/01/09 06:42:03 perry Exp $
   2 .\"
   3 .\" Copyright (c) 1989 The Regents of the University of California.
   4 .\" All rights reserved.
   5 .\"
   6 .\" Redistribution and use in source and binary forms, with or without
   7 .\" modification, are permitted provided that the following conditions
   8 .\" are met:
   9 .\" 1. Redistributions of source code must retain the above copyright
  10 .\"    notice, this list of conditions and the following disclaimer.
  11 .\" 2. Redistributions in binary form must reproduce the above copyright
  12 .\"    notice, this list of conditions and the following disclaimer in the
  13 .\"    documentation and/or other materials provided with the distribution.
  14 .\" 3. Neither the name of the University nor the names of its contributors
  15 .\"    may be used to endorse or promote products derived from this software
  16 .\"    without specific prior written permission.
  17 .\"
  18 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
  19 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  20 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  21 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
  22 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  23 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  24 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  25 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  26 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  27 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  28 .\" SUCH DAMAGE.
  29 .\"
  30 .\"     @(#)2.t 5.1 (Berkeley) 4/17/91
  31 .\"
  32 .NH
  33 System Development
  34 .PP
  35 The first phase of each Berkeley system is its development.
  36 .SM CSRG
  37 maintains a continuously evolving list of projects that are candidates
  38 for integration into the system.
  39 Some of these are prompted by emerging ideas from the research world,
  40 such as the availability of a new technology, while other additions
  41 are suggested by the commercial world, such as the introduction of
  42 new standards like
  43 .SM POSIX ,
  44 and still other projects are emergency responses to situations like
  45 the Internet Worm.
  46 .PP
  47 These projects are ordered based on the perceived benefit of the
  48 project as opposed to its difficulty;
  49 the most important are selected for inclusion in each new release.
  50 Often there is a prototype available from a group outside
  51 .SM CSRG .
  52 Because of the limited staff at
  53 .SM CSRG ,
  54 this prototype is obtained to use as a starting base
  55 for integration into the
  56 .SM BSD
  57 system.
  58 Only if no prototype is available is the project begun in-house.
  59 In either case, the design of the facility is forced to conform to the
  60 .SM CSRG
  61 style.
  62 .PP
  63 Unlike other development groups, the staff of
  64 .SM CSRG
  65 specializes by projects rather than by particular parts
  66 of the system;
  67 a staff person will be responsible for all aspects of a project.
  68 This responsibility starts at the associated kernel device drivers;
  69 it proceeds up through the rest of the kernel,
  70 through the C library and system utility programs,
  71 ending at the user application layer.
  72 This staff person is also responsible for related documentation,
  73 including manual pages.
  74 Many projects proceed in parallel,
  75 interacting with other projects as their paths cross.
  76 .PP
  77 All source code, documentation, and auxiliary files are kept
  78 under a source code control system.
  79 During development,
  80 this control system is critical for notifying people
  81 when they are colliding with other ongoing projects.
  82 Even more important, however,
  83 is the audit trail maintained by the control system that
  84 is critical to the release engineering phase of the project
  85 described in the next section.
  86 .PP
  87 Much of the development of
  88 .SM BSD
  89 is done by personnel that are located at other institutions.
  90 Many of these people not only have interim copies of the release
  91 running on their own machines,
  92 but also have user accounts on the main development
  93 machine at Berkeley.
  94 Such users are commonly found logged in at Berkeley over the
  95 Internet, or sometimes via telephone dialup, from places as far away
  96 as Massachusetts or Maryland, as well as from closer places, such as
  97 Stanford.
  98 For the \*(b3 release,
  99 certain users had permission to modify the master copy of the
 100 system source directly.
 101 People given access to the master sources
 102 are carefully screened beforehand,
 103 but are not closely supervised.
 104 Their work is checked at the end of the beta-test period by
 105 .SM CSRG
 106 personnel who back out inappropriate changes.
 107 Several facilities, including the
 108 Fortran and C compilers,
 109 as well as important system programs, for example,
 110 .PN telnet
 111 and
 112 .PN ftp ,
 113 include significant contributions from people who did not work
 114 directly for
 115 .SM CSRG .
 116 One important exception to this approach is that changes to the kernel
 117 are made only by
 118 .SM CSRG
 119 personnel, although the changes are often suggested by the larger community.
 120 .PP
 121 The development phase continues until
 122 .SM CSRG
 123 decides that it is appropriate to make a release.
 124 The decision to halt development and transition to release mode
 125 is driven by several factors.
 126 The most important is that enough projects have been completed
 127 to make the system significantly superior to the previously released
 128 version of the system.
 129 For example,
 130 \*(b3 was released primarily because of the need for
 131 the improved networking capabilities and the markedly
 132 improved system performance.
 133 Of secondary importance is the issue of timing.
 134 If the releases are too infrequent, then
 135 .SM CSRG
 136 will be inundated with requests for interim releases.
 137 Conversely,
 138 if systems are released too frequently,
 139 the integration cost for many vendors will be too high,
 140 causing them to ignore the releases.
 141 Finally,
 142 the process of release engineering is long and tedious.
 143 Frequent releases slow the rate of development and
 144 cause undue tedium to the staff.