Fix spelling mistakes in the documentation
Change-Id: If74b7b502459573eebf764bdc89f8a01b0d65cce
This commit is contained in:
parent
7502a46532
commit
92463561dd
@ -348,7 +348,7 @@ refs/meta/config
|
||||
|
||||
This is where the Gerrit configuration of each project is residing. This
|
||||
branch contains several files of importance: +project.config+, +groups+ and
|
||||
+rules.pl+. Torgether they control access and behaviour during the change
|
||||
+rules.pl+. Torgether they control access and behavior during the change
|
||||
review process.
|
||||
|
||||
|
||||
|
@ -18,7 +18,7 @@ is currently performing, or will perform in the near future.
|
||||
Gerrit contains an internal scheduler, similar to cron, that it
|
||||
uses to queue and dispatch both short and long term activity.
|
||||
|
||||
Tasks that are completed or cancelled exit the queue very quickly
|
||||
Tasks that are completed or canceled exit the queue very quickly
|
||||
once they enter this state, but it can be possible to observe tasks
|
||||
in these states.
|
||||
|
||||
|
@ -14,7 +14,7 @@ DESCRIPTION
|
||||
-----------
|
||||
|
||||
Provides a portal into the major events occurring on the server,
|
||||
outputing activity data in real-time to the client. Events are
|
||||
outputting activity data in real-time to the client. Events are
|
||||
filtered by the caller's access permissions, ensuring the caller
|
||||
only receives events for changes they can view on the web, or in
|
||||
the project repository.
|
||||
|
@ -509,7 +509,7 @@ made to this table, this cache should be flushed.
|
||||
cache `"adv_bases"`::
|
||||
+
|
||||
Used only for push over smart HTTP when branch level access controls
|
||||
are enabled. The cache entry contains all commits that are avaliable
|
||||
are enabled. The cache entry contains all commits that are available
|
||||
for the client to use as potential delta bases. Push over smart HTTP
|
||||
requires two HTTP requests, and this cache tries to carry state from
|
||||
the first request into the second to ensure it can complete.
|
||||
@ -683,7 +683,7 @@ cache.diff_intraline.enabled::
|
||||
Boolean to enable or disable the computation of intraline differences
|
||||
when populating a diff cache entry. This flag is provided primarily
|
||||
as a backdoor to disable the intraline difference feature if
|
||||
necessary. To maintain backwards compatability with prior versions,
|
||||
necessary. To maintain backwards compatibility with prior versions,
|
||||
this setting will fallback to `cache.diff.intraline` if not set in the
|
||||
configuration.
|
||||
+
|
||||
@ -935,7 +935,7 @@ Default on JGit is 128 file descriptors on all platforms.
|
||||
Largest object size, in bytes, that JGit will allocate as a
|
||||
contiguous byte array. Any file revision larger than this threshold
|
||||
will have to be streamed, typically requiring the use of temporary
|
||||
files under '$GIT_DIR/objects' to implement psuedo-random access
|
||||
files under '$GIT_DIR/objects' to implement pseudo-random access
|
||||
during delta decompression.
|
||||
+
|
||||
Servers with very high traffic should set this to be larger than
|
||||
@ -960,7 +960,7 @@ mapped segment is no longer in use before a call to `munmap()`
|
||||
can be made by the JVM native code.
|
||||
+
|
||||
In server applications (such as Gerrit) that need to access many
|
||||
pack files, setting this to true risks artifically running out
|
||||
pack files, setting this to true risks artificially running out
|
||||
of virtual address space, as the garbage collector cannot reclaim
|
||||
unused mapped spaces fast enough.
|
||||
+
|
||||
@ -1607,7 +1607,7 @@ By default, 2, which should be suitable for most high-traffic sites.
|
||||
+
|
||||
Minimum number of spare threads to keep in the worker thread pool.
|
||||
This number must be at least 1 larger than httpd.acceptorThreads
|
||||
multipled by the number of httpd.listenUrls configured.
|
||||
multiplied by the number of httpd.listenUrls configured.
|
||||
+
|
||||
By default, 5, suitable for most lower-volume traffic sites.
|
||||
|
||||
@ -1962,7 +1962,7 @@ See Java documentation on how to create the krb5.ini file.
|
||||
Note the `renewTGT` property to make sure the TGT does not expire,
|
||||
and `useTicketCache` to use the TGT supplied by the operating system. As
|
||||
the whole point of using GSSAPI is to have passwordless authentication
|
||||
to the LDAP service, this option does not aquire a new TGT on its own.
|
||||
to the LDAP service, this option does not acquire a new TGT on its own.
|
||||
|
||||
On Windows servers the registry key `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters`
|
||||
must have the DWORD value `allowtgtsessionkey` set to 1 and the account must not
|
||||
@ -2119,7 +2119,7 @@ main receive thread will also perform a change creation or patch
|
||||
set update.
|
||||
+
|
||||
Defaults to 1, using only the main receive thread. This feature is for
|
||||
databases with very high latency that can benfit from concurrent
|
||||
databases with very high latency that can benefit from concurrent
|
||||
operations when multiple changes are impacted at once.
|
||||
|
||||
[[receive.timeout]]receive.timeout::
|
||||
@ -2130,7 +2130,7 @@ and updating references, not the time to index the pack. Values can
|
||||
be specified using standard time unit abbreviations ('ms', 'sec',
|
||||
'min', etc.).
|
||||
+
|
||||
Default is 2 minutes. If no unit is specified, millisconds
|
||||
Default is 2 minutes. If no unit is specified, milliseconds
|
||||
is assumed.
|
||||
|
||||
|
||||
@ -2185,7 +2185,7 @@ field of any generated email messages. The supported values are:
|
||||
* `USER`
|
||||
+
|
||||
Gerrit will set the From header to use the current user's
|
||||
Full Name and Preferred Email. This may cause messsages to be
|
||||
Full Name and Preferred Email. This may cause messages to be
|
||||
classified as spam if the user's domain has SPF or DKIM enabled
|
||||
and <<sendemail.smtpServer,sendemail.smtpServer>> is not a trusted
|
||||
relay for that domain.
|
||||
@ -2410,7 +2410,7 @@ non-interactive users.
|
||||
+
|
||||
If the number of threads requested for non-interactive users is larger
|
||||
than the total number of threads allocated in sshd.threads, then the
|
||||
value of sshd.threads is increased to accomodate the requested value.
|
||||
value of sshd.threads is increased to accommodate the requested value.
|
||||
+
|
||||
By default, 0.
|
||||
|
||||
|
@ -127,7 +127,7 @@ Highlighted/additional styling notes:
|
||||
in the formatting guidelines. This is especially true within the
|
||||
same file.
|
||||
* Review your change in Gerrit to see if it highlights
|
||||
mistakingly deleted/added spaces on lines, trailing spaces.
|
||||
mistakenly deleted/added spaces on lines, trailing spaces.
|
||||
* Line length should be 80 or less, unless the code reads
|
||||
better with something slightly longer. Shorter lines not only
|
||||
help reviewers who may use a tablet to review the code, but future
|
||||
|
@ -445,7 +445,7 @@ Latency
|
||||
-------
|
||||
|
||||
Gerrit targets for sub-250 ms per page request, mostly by using
|
||||
very compact JSON payloads bewteen client and server. However, as
|
||||
very compact JSON payloads between client and server. However, as
|
||||
most of the serving stack (network, hardware, metadata
|
||||
database) is out of control of the Gerrit developers, no real
|
||||
guarantees can be made about latency.
|
||||
@ -474,7 +474,7 @@ parameters such as the following:
|
||||
Out of the box, Gerrit will handle the "Default Maximum". Site
|
||||
administrators may reconfigure their servers by editing gerrit.config
|
||||
to run closer to the estimated maximum if sufficient memory is made
|
||||
avaliable to the JVM and the relevant cache.*.memoryLimit variables
|
||||
available to the JVM and the relevant cache.*.memoryLimit variables
|
||||
are increased from their defaults.
|
||||
|
||||
Discussion
|
||||
@ -671,7 +671,7 @@ Backups
|
||||
|
||||
PostgreSQL and MySQL can be configured to replicate their data to
|
||||
other systems, where they are applied to a warm-standby backup in
|
||||
real time. Gerrit instances which care about reduduncy will setup
|
||||
real time. Gerrit instances which care about redundancy will setup
|
||||
this feature of PostgreSQL or MySQL to ensure the warm-standby is
|
||||
reasonably current should the master go offline.
|
||||
|
||||
@ -699,7 +699,7 @@ occurred, and the Gerrit account identity of who did the upload.
|
||||
Changes submitted and merged into a branch also update the
|
||||
Git reflog. These logs are available only to the Gerrit site
|
||||
administrator, and they are not replicated through the automatic
|
||||
replication noted earlier. These logs are primarly recorded for an
|
||||
replication noted earlier. These logs are primarily recorded for an
|
||||
"oh s**t" moment where the administrator has to rewind data. In most
|
||||
installations they are a waste of disk space. Future versions of
|
||||
JGit may allow disabling these logs, and Gerrit may take advantage
|
||||
|
@ -193,7 +193,7 @@ credentials and possibly verify connectivity to validate them.
|
||||
====
|
||||
|
||||
MyInitStep needs to follow the standard Gerrit InitStep syntax
|
||||
and behaviour: writing to the console using the injected ConsoleUI
|
||||
and behavior: writing to the console using the injected ConsoleUI
|
||||
and accessing / changing configuration settings using Section.Factory.
|
||||
|
||||
In addition to the standard Gerrit init injections, plugins receive
|
||||
|
@ -21,7 +21,7 @@ Installation
|
||||
link:install.html#init[site initialization] tasks described
|
||||
in the standard installation documentation.
|
||||
|
||||
* Stop the embedded deamon that was automatically started by 'init':
|
||||
* Stop the embedded daemon that was automatically started by 'init':
|
||||
+
|
||||
----
|
||||
review_site/bin/gerrit.sh stop
|
||||
|
@ -20,7 +20,7 @@ OPTIONS
|
||||
-s::
|
||||
Dynamically load the Prolog source code at startup,
|
||||
as though the user had entered `['FILE.pl'].` into
|
||||
the interepter once it was running. This option may
|
||||
the interpreter once it was running. This option may
|
||||
be supplied more than once to load multiple files.
|
||||
|
||||
EXAMPLES
|
||||
|
@ -182,7 +182,7 @@ Here some examples of possible return values from the `submit_rule` predicate:
|
||||
<2> label `'Verified'` is rejected. Change is not submittable.
|
||||
<3> label `'Author-is-John-Doe'` is needed for the change to become submittable.
|
||||
Note that this tells nothing about how this criteria will be met. It is up
|
||||
to the implementor of the `submit_rule` to return `label('Author-is-John-Doe',
|
||||
to the implementer of the `submit_rule` to return `label('Author-is-John-Doe',
|
||||
ok(_))` when this criteria is met. Most likely, it will have to match
|
||||
against `gerrit:commit_author` in order to check if this criteria is met.
|
||||
This will become clear through the examples below.
|
||||
@ -645,7 +645,7 @@ understand.
|
||||
|
||||
Reusing the default submit policy
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
To get results of Gerrits default submit policy we use the
|
||||
To get results of Gerrit's default submit policy we use the
|
||||
`gerrit:default_submit` predicate. The `gerrit:default_submit(X)` includes all
|
||||
categories from the database. This means that if we write a submit rule like:
|
||||
|
||||
@ -743,7 +743,7 @@ Let's implement the same submit rule the other way, without reusing the
|
||||
The latter implementation is probably easier to understand and the code looks
|
||||
cleaner. Note, however, that the latter implementation will always return the
|
||||
two standard categories only (`Code-Review` and `Verified`) even if a new
|
||||
category has beeen inserted into the database. To include the new category
|
||||
category has been inserted into the database. To include the new category
|
||||
the `rules.pl` would need to be modified or a `submit_filter` in a parent
|
||||
project would have to care about including the new category in the result
|
||||
of this `submit_rule`.
|
||||
|
@ -44,7 +44,7 @@ characters, as some users may find one more readable than another:
|
||||
`&` or `;` or `,`
|
||||
|
||||
The special `foreach=...` parameter is designed to facilitate
|
||||
more easily writting similar queries in a dashboard. The value of the
|
||||
more easily writing similar queries in a dashboard. The value of the
|
||||
foreach parameter will be used in every query in the dashboard by
|
||||
appending it to their ends with a space (ANDing it with the queries).
|
||||
|
||||
|
@ -275,7 +275,7 @@ Argument Quoting
|
||||
----------------
|
||||
|
||||
Operator values that are not bare words (roughly A-Z, a-z, 0-9, @,
|
||||
hypen, dot and underscore) must be quoted for the query parser.
|
||||
hyphen, dot and underscore) must be quoted for the query parser.
|
||||
|
||||
Quoting is accepted as either double quotes
|
||||
(e.g. `message:"the value"`) or as matched
|
||||
@ -288,8 +288,8 @@ Boolean Operators
|
||||
Unless otherwise specified, operators are joined using the `AND`
|
||||
boolean operator, thereby restricting the search results.
|
||||
|
||||
Parentheses can be used to force a particular precendence on complex
|
||||
operator expressions, otherwise OR has higher precendence than AND.
|
||||
Parentheses can be used to force a particular precedence on complex
|
||||
operator expressions, otherwise OR has higher precedence than AND.
|
||||
|
||||
Negation
|
||||
~~~~~~~~
|
||||
@ -308,7 +308,7 @@ results, returning only changes that match both operators.
|
||||
OR
|
||||
~~
|
||||
The boolean operator `OR` (in all caps) can be used to find changes
|
||||
that match either operator. This increases the nubmer of results
|
||||
that match either operator. This increases the number of results
|
||||
that are returned, as more changes are considered.
|
||||
|
||||
|
||||
|
@ -104,10 +104,10 @@ has at least reviewed the patch and has indicated acceptance. Hence patch
|
||||
mergers will sometimes manually convert an acker's "yep, looks good to me"
|
||||
into an Acked-by:.
|
||||
|
||||
Acked-by: does not necessarily indicate acknowledgement of the entire patch.
|
||||
Acked-by: does not necessarily indicate acknowledgment of the entire patch.
|
||||
For example, if a patch affects multiple subsystems and has an Acked-by: from
|
||||
one subsystem maintainer then this usually indicates acknowledgement of just
|
||||
the part which affects that maintainer's code. Judgement should be used here.
|
||||
one subsystem maintainer then this usually indicates acknowledgment of just
|
||||
the part which affects that maintainer's code. Judgment should be used here.
|
||||
When in doubt people should refer to the original discussion in the mailing
|
||||
list archives.
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user