From: Gervase Markham Date: Tue, 16 Sep 2014 08:39:01 +0000 (+0800) Subject: Some changes from glob's first feedback X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=37d6d4b9222a028cc1ab9c71b7ee0b2dc2f3b4cf;p=thirdparty%2Fbugzilla.git Some changes from glob's first feedback --- diff --git a/docs/en/rst/administering/categorization.rst b/docs/en/rst/administering/categorization.rst index b34fdf8a99..f9ab5b2bdc 100644 --- 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 8d8cd587cf..d825b8fe92 100644 --- 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 50e13d739b..b6e9d8eb16 100644 --- 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 6ded514e85..e433d52801 100644 --- 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 07309576ad..4dbdb807f1 100644 --- 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.