Some changes from glob's first feedback

diff --git a/docs/en/rst/administering/categorization.rst b/docs/en/rst/administering/categorization.rst
index b34fdf8a990e61ae729e88d2daecaf7240e6ab3d..f9ab5b2bdcd186cff906ebff89a8ab29cf5cfbc6 100644 (file)
--- a/docs/en/rst/administering/categorization.rst
+++ b/docs/en/rst/administering/categorization.rst
@@ -65,8 +65,7 @@ Default milestone
     Select the default milestone for this product.
 
 Version
-    Specify which version of the product bugs will be
-    entered against. XXX is this the "default version" in any sense?
+    Specify the default version for this product.
 
 Create chart datasets for this product
     Select to make chart datasets available for this product.

diff --git a/docs/en/rst/administering/parameters.rst b/docs/en/rst/administering/parameters.rst
index 8d8cd587cf793b108aea299e541c13245756b5d9..d825b8fe923487a0549f91e270e816cf8219a544 100644 (file)
--- a/docs/en/rst/administering/parameters.rst
+++ b/docs/en/rst/administering/parameters.rst
@@ -230,10 +230,10 @@ attachment_base
     XXX So this requires wildcard DNS? We should explain a bit about what is needed here.
 
 allow_attachment_deletion
-    If this option is on, administrators will be able to delete the content of attachments.
+    If this option is on, administrators will be able to delete the contents
+    of attachments (i.e. replace the attached file with a 0 byte file),
+    leaving only the metadata.
 
-    XXX Does the attachment itself still exist, it's just empty?
-    
 maxattachmentsize
     The maximum size (in kilobytes) of attachments to be stored in the database. If a file larger than this size is attached to a bug, Bugzilla will look at the maxlocalattachment parameter to determine if the file can be stored locally on the web server. If the file size exceeds both limits, then the attachment is rejected. Settings both parameters to 0 will prevent attaching files to bugs.
 
@@ -706,24 +706,35 @@ max_search_results
 Shadow Database
 ===============
 
-This page controls whether a shadow database is used, and all the
-parameters associated with the shadow database. Versions of Bugzilla
-prior to 3.2 used the MyISAM table type, which supports
-only table-level write locking. With MyISAM, any time someone is making a change to
-a bug, the entire table is locked until the write operation is complete.
-Locking for write also blocks reads until the write is complete.
+This page controls whether a shadow database is used. If your Bugzilla is
+not large, you will not need these options.
+
+A standard large database setup involves a single master server and a pool of
+read-only slaves (which Bugzilla calls the "shadowdb"). Queries which are not
+updating data can be directed to the slave pool, removing the load/locking
+from the master, freeing it up to handle writes. Bugzilla will switch to the
+shadowdb when it knows it doesn't need to update the database (e.g. when
+searching, or displaying a bug to a not-logged-in user).
+
+Bugzilla does not make sure the shadowdb is kept up to date so if you use
+one, you will need to set up replication in your database server.
+
+If your shadowdb is on a different machine, specify :param:`shadowdbhost`
+and :param:`shadowdbport`. If it's on the same machine, specify
+:param:`shadowdbsock`.
+
+shadowdbhost
+    The host the shadow database is on.
 
-The ``shadowdb`` parameter was designed to get around
-this limitation. While only a single user is allowed to write to
-a table at a time, reads can continue unimpeded on a read-only
-shadow copy of the database.
+shadowdbport
+    The port the shadow database is on.
 
-.. note:: As of version 3.2, Bugzilla no longer uses the MyISAM table type.
-   Instead, InnoDB is used, which can do transaction-based locking.
-   Therefore, the limitations the Shadow Database feature was designed
-   to workaround no longer exist.
+shadowdbsock
+    The socket used to connect to the shadow database, if the host is the
+    local machine.
 
-XXX Do we need to document it, then? Or even still support it?
+shadowdb
+    The database name of the shadow database.
 
 .. _admin-memcached:
 

diff --git a/docs/en/rst/installing/mysql.rst b/docs/en/rst/installing/mysql.rst
index 50e13d739b2a913f6fafb85cde591cbf8e3300c5..b6e9d8eb16d51eb52f44de5e50f5ba0f9c505416 100644 (file)
--- a/docs/en/rst/installing/mysql.rst
+++ b/docs/en/rst/installing/mysql.rst
@@ -69,11 +69,9 @@ combination of all comments on a single bug could in some cases
 be larger than 1MB.
 
 We recommend that you allow at least 16MB packets by
-adding the ``max_allowed_packet`` parameter to your MySQL
+adding or altering the ``max_allowed_packet`` parameter in your MySQL
 configuration in the ``[mysqld]`` section, like this:
 
-XXX is "adding" right? Surely it's normally present?
-
 ::
 
     [mysqld]

diff --git a/docs/en/rst/installing/quick-start.rst b/docs/en/rst/installing/quick-start.rst
index 6ded514e8592e3137e4211cf1bd89d14a2e280aa..e433d52801f85f7002d0b1342aeac534a74c56cd 100644 (file)
--- a/docs/en/rst/installing/quick-start.rst
+++ b/docs/en/rst/installing/quick-start.rst
@@ -147,10 +147,6 @@ home page. It requires a little familiarity with Linux and the command line.
    XXX Given this is a quick setup on a dedicated box, is it OK to use the
    MySQL root user?
     
-   XXX Why can't checksetup determine webservergroup automatically,
-   and prompt for db_user and db_pass, and just keep going? Perhaps with a
-   --simple switch?
-
 10. Check Setup (again)
 
     Run the :file:`checksetup.pl` script again to set up the database.

diff --git a/docs/en/rst/maintaining/merging-accounts.rst b/docs/en/rst/maintaining/merging-accounts.rst
index 07309576ad263de668ce8de6092c611b7e04478a..4dbdb807f1aa3b6604b91801d5d3f0f9082c2692 100644 (file)
--- a/docs/en/rst/maintaining/merging-accounts.rst
+++ b/docs/en/rst/maintaining/merging-accounts.rst
@@ -1,9 +1,14 @@
 Merging Accounts
 ################
 
-Sometimes, users accidentally create a second account and do things with it,
-perhaps because they don't realise they can change the email address
-associated with their account. And then they don't want to abandon the
-history associated with either.
+Sometimes, users create a second account, perhaps because they don't realise
+they can change the email address associated with their original account.
+And then, once they discover this, they don't want to abandon the history
+associated with either account.
 
-XXX BMO's merge accounts script?
+The best way forward in this case would be to merge one of their accounts
+into the other one, so it looked like the target account had done all the
+actions of both. In Bugzilla's :file:`contrib` directory, there is a script
+called :file:`merge-users.pl`. While code in this directory is not officially
+supported by the Bugzilla team, this script may be useful to you in
+solving the above problem.