Start new sentences on new lines.
authorSascha Wildner <saw@online.de>
Wed, 3 Dec 2008 00:56:45 +0000 (01:56 +0100)
committerSascha Wildner <saw@online.de>
Wed, 3 Dec 2008 00:56:51 +0000 (01:56 +0100)
share/man/man7/committer.7

index 48424f9..734b3e0 100644 (file)
@@ -68,8 +68,9 @@ key to give you access.
 .Pp
 Your
 .Pa crater
-account is set up for git repository only. It can
-only operate as a git slave and cannot be logged into.  That is,
+account is set up for git repository only.
+It can only operate as a git slave and cannot be logged into.
+That is,
 .Pa crater.dragonflybsd.org
 is only used as part of
 .Nm git Cm push
@@ -77,16 +78,19 @@ operations.
 .Pp
 Your
 .Pa leaf
-account is a general developer account.  Any
+account is a general developer account.
+Any
 .Dx
 developer can have a
 .Pa leaf
 account, whether a committer or not.
 It can be useful as a developer rendezvous,
-however.  For example, people upload kernel cores to
+however.
+For example, people upload kernel cores to
 .Pa leaf
 so other
-developers can look at them.  You log into your
+developers can look at them.
+You log into your
 .Pa leaf
 account with:
 .Pp
@@ -121,13 +125,12 @@ git commit file_you_edited
 git push crater
 .Ed
 .Sh COMMITTING REAL WORK
-Make modifications as needed.  For example, edit files.  If adding
-new files make git aware of them like this.  Files and directories can just be
-added locally.
-These
-operations do not actually affect the master repository.
-Instead they are
-stored in your local copy of the repository and then
+Make modifications as needed.
+For example, edit files.
+If adding new files make git aware of them like this.
+Files and directories can just be added locally.
+These operations do not actually affect the master repository.
+Instead they are stored in your local copy of the repository and then
 synchronized to the repository when you
 .Nm git Cm push .
 .Bd -literal -offset indent
@@ -168,13 +171,15 @@ issue tracker id's etc).
 The reason is that many git tools display the first line as summary.
 .Sh DISCUSSING COMMITTABLE WORK BEFORE HAND
 Discussion prior to commit usually occurs on the kernel@, submit@, or bugs@
-mailing lists.  It depends on the work involved.  Simple and obvious work,
+mailing lists.
+It depends on the work involved.
+Simple and obvious work,
 such as documentation edits or additions, don't really need a head's up.
 .Pp
 Simple and obvious bug fixes don't need a head's up, other than to
 say that you will (or just have) committed the fix, so you don't
-race other committers trying to do the same thing.  Usually the
-developer most active in a discussion about a bug commits the
+race other committers trying to do the same thing.
+Usually the developer most active in a discussion about a bug commits the
 fix, but it isn't considered a big deal.
 .Pp
 More complex issues are usually discussed on the lists first.
@@ -182,20 +187,21 @@ Non-trivial but straight forward bug fixes usually go through
 a testing period, where you say something like:
 .Do
 Here is a patch
-to driver BLAH that fixes A, B, and C, please test it.  If there
-are no objections I will commit it next Tuesday.
+to driver BLAH that fixes A, B, and C, please test it.
+If there are no objections I will commit it next Tuesday.
 .Dc
 (usually a week,
 or more depending on the complexity of the patch).
 .Pp
-New drivers or utilities are usually discussed.  Committers will
-often commit new work
+New drivers or utilities are usually discussed.
+Committers will often commit new work
 .Em without
 hooking it into the buildworld or
 buildkernel infrastructure in order to be able to continue
 development on it in piecemeal without having to worry about it
 breaking buildworld or buildkernel, and then they hook it in as a
-last step after they've stabilized it.  Examples of this include
+last step after they've stabilized it.
+Examples of this include
 new versions of GCC, updates to vendor packages such as bind,
 sendmail, etc.
 .Sh DEVELOPER LOCKS
@@ -203,9 +209,11 @@ Areas within the repository are never explicitly locked.
 Often situations will arise where one developer commits work and
 another developer finds an issue with it that needs to be corrected.
 .Pp
-All committed work becomes community property.  No developer has a
+All committed work becomes community property.
+No developer has a
 .Sq lock
-on any part of the source tree.  However, if a developer is
+on any part of the source tree.
+However, if a developer is
 actively working on a portion of the source tree and you find a bug
 or other issue, courtesy dictates that you post to kernel@ and/or
 email the developer.
@@ -217,12 +225,12 @@ commit, though you should still post to the kernel@ mailing list
 and, of course, confer with developers when their expertise is
 needed.
 .Pp
-One exception to this rule is documentation.  If any developer commits
-new work, the documentation guys have free reign to go in and
-correct
+One exception to this rule is documentation.
+If any developer commits
+new work, the documentation guys have free reign to go in and correct
 .Xr mdoc 7
-errors.  This is really a convenience as most developers
-are not
+errors.
+This is really a convenience as most developers are not
 .Xr mdoc 7
 gurus and it's a waste of time for the doc guys to post
 to kernel@ for all the little corrections they make.
@@ -230,17 +238,21 @@ to kernel@ for all the little corrections they make.
 On the occasion that a major code conflict occurs, for example if two
 people are doing major work in the same area of the source tree and forgot
 to collaborate with each other, the project leader will be responsible for
-resolving the conflict.  Again, the repository is considered community
+resolving the conflict.
+Again, the repository is considered community
 property and it must be acceptable for any developer to be able to work on
 any area of the tree that he or she has an interest in.
 .Sh MAJOR ARCHITECTURAL CHANGES
-This is generally Matt Dillon's area of expertise.  All major architectural
+This is generally Matt Dillon's area of expertise.
+All major architectural
 changes must be discussed on the kernel@ mailing list and he retains
 veto power.
 .Pp
-This isn't usually an issue with any work.  At best if something
+This isn't usually an issue with any work.
+At best if something
 doesn't look right architecturally he'll chip in with adjustments to
-make it fit in.  Nothing ever really gets vetoed.
+make it fit in.
+Nothing ever really gets vetoed.
 .Sh SEE ALSO
 .Xr git 1 Pq Pa pkgsrc/devel/scmgit ,
 .Xr development 7