1 .\" Copyright (c) 2003,2004 The DragonFly Project. All rights reserved.
3 .\" This code is derived from software contributed to The DragonFly Project
4 .\" by Matthew Dillon <dillon@backplane.com>
6 .\" Redistribution and use in source and binary forms, with or without
7 .\" modification, are permitted provided that the following conditions
10 .\" 1. Redistributions of source code must retain the above copyright
11 .\" notice, this list of conditions and the following disclaimer.
12 .\" 2. Redistributions in binary form must reproduce the above copyright
13 .\" notice, this list of conditions and the following disclaimer in
14 .\" the documentation and/or other materials provided with the
16 .\" 3. Neither the name of The DragonFly Project nor the names of its
17 .\" contributors may be used to endorse or promote products derived
18 .\" from this software without specific, prior written permission.
20 .\" THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
21 .\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
22 .\" LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
23 .\" FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
24 .\" COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
25 .\" INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES (INCLUDING,
26 .\" BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
27 .\" LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
28 .\" AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
29 .\" OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
30 .\" OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
33 .\" $DragonFly: src/share/man/man7/committer.7,v 1.10 2008/03/16 11:10:48 swildner Exp $
40 .Nd rules for DragonFly committers
41 .Sh CVS REPOSITORY ON YOUR LOCAL MACHINE
46 CVS repository itself onto your local box
47 (if you haven't already). See the file
48 .Pa /usr/share/examples/cvsup/DragonFly-cvs-supfile .
50 You basically want to do all CVS operations not related to commits
51 via your local repository, and do commit operations directly to
54 We strongly recommend that you set up a
57 cvsup at least once a day, so your local CVS repository is always
59 .Sh CHECKING OUT THE SOURCES
63 .Bd -literal -offset indent
70 Checking out and updating a checked out source tree:
71 .Bd -literal -offset indent
73 cvs -d /home/dcvs checkout src
74 cvs -d /home/dcvs update src
79 recommend that you use a cron job to
82 checked out source. Automatic updates can interfere with
83 any work-in-progress that you have.
85 The CVS repository machine is
86 .Pa crater.dragonflybsd.org ,
90 .Pa leaf.dragonflybsd.org .
92 an account for you on both machines and install your public SSH
93 key to give you access.
97 account is set up for CVS repository only. It can
98 only operate as a CVS slave and cannot be logged into. That is,
99 .Pa crater.dragonflybsd.org
100 is only used as part of
106 account is a general developer account. Any
110 account, whether a committer or not.
111 It can be useful as a developer rendezvous,
112 however. For example, people upload kernel cores to
115 developers can look at them. You log into your
119 .Li ssh you@leaf.dragonflybsd.org
121 The rules for account use are in
124 It is very important that you never install a password or create a SSH
127 to use to access other machines.
128 Because non-committers can have
134 .Sh TESTING COMMIT ACCESS
135 There is a directory called
136 .Pa /usr/src/test/test .
138 access, try making a modification and committing a file in this
141 .Bd -literal -offset indent
142 cd /usr/src/test/test
144 cvs -d you@crater.dragonflybsd.org:/cvs commit file_you_edited
146 .Sh COMMITTING REAL WORK
147 Make modifications as needed. For example, edit files. If adding
148 new files make CVS aware of them like this. Files can just be
149 added locally, but directories have to run through
152 operations do not actually affect the repository (except directories
153 being added are mkdir'd in the repository). Instead they are
154 stored in the checkout source's
156 subdirectory and then
157 synchronized to the repository when you
160 .Bd -literal -offset indent
162 cvs -d you@crater.dragonflybsd.org:/cvs add directory
165 To commit to the repository, use:
166 .Bd -literal -offset indent
167 cvs -d you@crater.dragonflybsd.org:/cvs commit files_or_directories
170 The recommended way for committing to a specific branch (to merge bug fixes,
173 the branch in a different directory, modify there, and commit normally:
174 .Bd -literal -offset indent
175 cvs checkout -r DragonFly_RELEASE_1_12 src
181 .Pa you@crater.dragonflybsd.org:/cvs .
182 The reason is that you want the default
185 sources to point at your local CVS repository, not at
187 This reduces instances where accidental commits or repository
188 operations are made on
192 .Nm cvs Cm update Ap ing
193 directly from the repository.
194 e.g. try to avoid doing
195 .Nm cvs Fl d Ar ... Cm update
200 to resync your local copy of the repository
204 .Nm cvs Fl d Ar /home/dcvs Cm update
206 your local copy of the repository.
208 The idea here is to try to avoid having CVS set its
210 file in any given checked out CVS directory to point at
212 You really want it to just point at your local copy of the CVS
219 operations. Such operations can be
220 very dangerous and only highly experienced CVS admins should
221 do them. That's basically just two or three people (Matt and Joerg
224 The best way to resynchronize your local CVS repository after
225 making a commit is to cvsup again.
226 .Sh DISCUSSING COMMITTABLE WORK BEFORE HAND
227 Discussion prior to commit usually occurs on the kernel@, submit@, or bugs@
228 mailing lists. It depends on the work involved. Simple and obvious work,
229 such as documentation edits or additions, don't really need a head's up.
231 Simple and obvious bug fixes don't need a head's up, other than to
232 say that you will (or just have) committed the fix, so you don't
233 race other committers trying to do the same thing. Usually the
234 developer most active in a discussion about a bug commits the
235 fix, but it isn't considered a big deal.
237 More complex issues are usually discussed on the lists first.
238 Non-trivial but straight forward bug fixes usually go through
239 a testing period, where you say something like:
242 to driver BLAH that fixes A, B, and C, please test it. If there
243 are no objections I will commit it next Tuesday.
246 or more depending on the complexity of the patch).
248 New drivers or utilities are usually discussed. Committers will
249 often commit new work
251 hooking it into the buildworld or
252 buildkernel infrastructure in order to be able to continue
253 development on it in piecemeal without having to worry about it
254 breaking buildworld or buildkernel, and then they hook it in as a
255 last step after they've stabilized it. Examples of this include
256 new versions of GCC, updates to vendor packages such as bind,
259 Areas within the CVS repository are never explicitly locked.
260 Often situations will arise where one developer commits work and
261 another developer finds an issue with it that needs to be corrected.
263 All committed work becomes community property. No developer has a
265 on any part of the source tree. However, if a developer is
266 actively working on a portion of the source tree and you find a bug
267 or other issue, courtesy dictates that you post to kernel@ and/or
270 This means that, generally, if you do not see a commit to an area
271 of the source tree in the last few weeks, it isn't considered active and
272 you don't really need to confer with the developer that made the
273 commit, though you should still post to the kernel@ mailing list
274 and, of course, confer with developers when their expertise is
277 One exception to this rule is documentation. If any developer commits
278 new work, the documentation guys have free reign to go in and
281 errors. This is really a convenience as most developers
284 gurus and it's a waste of time for the doc guys to post
285 to kernel@ for all the little corrections they make.
287 On the occasion that a major code conflict occurs, for example if two
288 people are doing major work in the same area of the source tree and forgot
289 to collaborate with each other, the project leader will be responsible for
290 resolving the conflict. Again, the repository is considered community
291 property and it must be acceptable for any developer to be able to work on
292 any area of the tree that he or she has an interest in.
293 .Sh MAJOR ARCHITECTURAL CHANGES
294 This is generally Matt Dillon's area of expertise. All major architectural
295 changes must be discussed on the kernel@ mailing list and he retains
298 This isn't usually an issue with any work. At best if something
299 doesn't look right architecturally he'll chip in with adjustments to
300 make it fit in. Nothing ever really gets vetoed.