share/doc/papers/relengr/2.t

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