aboutsummaryrefslogtreecommitdiff
path: root/handbook/current.sgml
blob: edca1767e01050f440c62e34cbad47f95296ca7e (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
<!-- $Id: current.sgml,v 1.2.4.1 1995-09-17 11:19:26 davidg Exp $ -->
<!-- The FreeBSD Documentation Project -->


<chapt><heading>Staying current with FreeBSD<label id="current"></heading>

<p><em>Contributed by &a.jkh;.</em>

<!--

                        THE FREEBSD CURRENT POLICY 

Last updated: $Date: 1995-09-17 11:19:26 $

This document attempts to explain the rationale behind FreeBSD-current,
what you should expect should you decide to run it, and states some
prerequisites for making sure the process goes as smoothly as possible.
-->

<sect><heading>What is FreeBSD-current?</heading>

<p>FreeBSD-current is, quite literally, nothing more than a daily snapshot of
the working sources for FreeBSD.  These include work in progress, experimental
changes, and transitional mechanisms that may or may not be present in
the next official release of the software.  While many of us compile
almost daily from FreeBSD-current sources, there are periods of time when
the sources are literally uncompilable.  These problems are generally resolved
as expeditiously as possible, but whether or not FreeBSD-current sources bring
disaster or greatly desired functionality can literally be a matter of which
part of any given 24 hour period you grabbed them in!

Under certain circumstances we will sometimes make binaries for parts of
FreeBSD-current available, but only because we're interested in getting
something tested, not because we're in the business of providing binary
releases of current.  If we don't offer, please don't ask!  It takes far
too much time to do this as a general task.

<sect><heading>Who needs FreeBSD-current?</heading>

<p>FreeBSD-current is made generally available for 3 primary interest groups:
<enum>
    <item>  Members of the FreeBSD group who are actively working on one
        part or another of the source tree and for whom keeping `current'
        is an absolute requirement.

    <item>  Members of the FreeBSD group who are active ALPHA or BETA testers
        and willing to spend time working through problems in order to
        ensure that FreeBSD-current remains as sane as possible.  These
        are also people who wish to make topical suggestions on changes
        and the general direction of FreeBSD.

    <item>  Peripheral members of the FreeBSD (or some other) group who merely
        wish to keep an eye on things and use the current sources for
        reference purposes (e.g. for <em>reading</em>, not running).  These
        people also make the occasional comment or contribute code.
</enum>

<sect><heading>What is FreeBSD-current <em>NOT</em>?</heading>

<p><enum>
    <item>  A fast-track to getting pre-release bits because there's something
        you heard was pretty cool in there and you want to be the first on
        your block to have it.

    <item>  A quick way of getting bug fixes.

    <item>  In any way ``officially supported'' by us.

        We do our best to help people genuinely in one of the 3
        ``legitimate'' FreeBSD-current catagories, but we simply <em>do not
        have the time</em> to help every person who jumps into FreeBSD-current
        with more enthusiasm than knowledge of how to deal with
        experimental system software.  This is not because we're mean and
        nasty people who don't like helping people out (we wouldn't even be
        doing FreeBSD if we were), it's literally because we can't answer
        400 messages a day <em>and</em> actually work on FreeBSD!  I'm sure if
        given the choice between having us answer lots of questions or
        continue to improve FreeBSD, most of you would vote for us
        improving it.
</enum>

<sect><heading>Using FreeBSD-current</heading>

<p><enum> <item> Join the freebsd-hackers and freebsd-commit
    mailing lists.  This is not just a good idea, it's
    <em>essential</em>.  If you aren't on freebsd-hackers, you
    won't read the comments that people are making about the
    current state of the system and thus will end up stumbling
    over a lot of problems that others have already found and
    solved.  Even more importantly, you will miss out on
    potentially critical information (e.g. ``Yo, Everybody!
    Before you rebuild <tt>/usr/src</tt>, you <em>must</em>
    rebuild the kernel or your system will crash horribly!").

    The freebsd-commit list will allow you to see the commit log
    entry for each change as its made.  This can also contain
    important information, and will let you know what parts of
    the system are being actively changed.

        To join these lists, send mail to `majordomo@FreeBSD.ORG'
        and say:
<verb>
            subscribe freebsd-hackers
            subscribe freebsd-commit
</verb>
        In the body of your message.  Optionally, you can also say `help'
        and MajorDomo will send you full help on how to subscribe and
        unsubscribe to the various other mailing lists we support.

    <item>  Grab the sources from ftp.FreeBSD.ORG.  You can do this in
        three ways:

    <enum>
	<item> Using the CTM facility desribed below.  Unless you 
            have a good TCP/IP connection at a flat rate, this is 
            the way to do it.

        <item>  Use the CMU `sup' program (Software Update
	     Protocol), also described below.
            This is the second most recommended method, since it allows 
	    you to grab the entire collection once and then only what's
            changed from then on.  Many people run sup from cron
            and keep their sources up-to-date automatically.

	    The problem is that sup does not use the bandwidth efficient,
	    unless the round-trip is very fast.  If the cost of connection
	    or the duration of the session is a concern, use CTM.

        <item>  Use ftp.  The source tree for FreeBSD-current is always
            "exported" on:
<verb>
             ftp.FreeBSD.ORG:~ftp/pub/FreeBSD/FreeBSD-current
</verb>
            We use `wu-ftpd' which allows compressed/tar'd grabbing
            of whole trees.  e.g. you see:
<verb>
            usr.bin/lex
</verb>
            You can do:
<verb>
            ftp> cd usr.bin
            ftp> get lex.tar.Z
</verb>
            And it will get the whole directory for you as a compressed
            tar file.
    </enum>

    <item>  If you're grabbing the sources to run, and not just look at,
	then grab <em>all</em> of current, not just selected portions.  The
	reason for this is that various parts of the source depend on
	updates elsewhere and trying to compile just a subset is almost
	guaranteed to get you into trouble.

    <item>  Before compiling current, read the Makefile in /usr/src
	carefully.  You'll see one-time targets like `bootstrapld'
	which <em><bf>must</bf></em> be run as part of the upgrading process.  Reading
	freebsd-hackers will keep you up-to-date on other bootstrapping
	procedures that sometimes become necessary as we move towards
	the next release.

    <item>  Be active!  If you're running FreeBSD-current, we want to know
	what you have to say about it, especially if you have suggestions
	for enhancements or bug fixes.  Suggestions with accompanying code
	are received most enthusiastically! 
</enum>

<!--
Thank you for taking the time to read this all the way through.  We're
always very keen to remain "open" and share the fruits of our labor
with the widest possible audience, but sharing development sources has
always had certain pitfalls associated with it (which is why most
commercial organizations won't even consider it) and I want to make
sure that people at least come into this with their eyes open, and
don't make the leap unless they're good at working without a net!
-->