Author: paul
Date: 2006-10-25 16:47:18 +0200 (Wed, 25 Oct 2006)
New Revision: 3739
Log:
r11239@frost: paul | 2006-10-25 09:46:42 -0500
Initial yank of service-pack-related material from the FAQ.
Added:
trunk/refman-5.0/service-pack.txt
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:14819
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:11233
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:10957
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:14819
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:11239
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:10957
Added: trunk/refman-5.0/service-pack.txt
===================================================================
--- trunk/refman-5.0/service-pack.txt (rev 0)
+++ trunk/refman-5.0/service-pack.txt 2006-10-25 14:47:18 UTC (rev 3739)
Changed blocks: 1, Lines Added: 244, Lines Deleted: 0; 10398 bytes
@@ -0,0 +1,244 @@
+3 Service-Pack, Hot-fix, and Bug-fix-Related FAQ
+
+3.1 In General, what are the differences between how Bugs are addressed
+in both the Community and Enterprise Server?
+
+In general, bugs are first corrected in the Enterprise Server code
+and then released to MySQL customers in regularly scheduled service
+pack drops. The same bug fixes are applied to the Community server
+also, but are not done so on a predictably scheduled basis and are
+released later than for Enterprise customers.
+
+In particular, when a MySQL version is ready for Enterprise release,
+we will create a second tree: one tree will be the Enterprise Server
+tree and the other will be the Community Server tree. Both trees
+will be available to the public.
+
+3.2 How can an open source user obtain the latest and up-to-date MySQL
+server code for a particular release?
+
+We will make our source available via Bitkeeper at
+http://mysql.bkbits.net/; instructions for building binaries from
+source can be found at
+http://dev.mysql.com/doc/refman/5.0/en/installing-source.html.
+
+This will always be available for community users.
+
+3.3 What is an Enterprise Server Service Pack?
+
+As part of the effort to continually improve MySQL AB software,
+security updates and bug fixes are created and regularly released
+for the MySQL Enterprise server in a batch format known as a service
+pack. Service packs are cumulative, meaning that each new service
+pack contains all the fixes that are included with previous service
+packs and any new fixes. This is done so that a customer does not
+have to install an earlier version of a service pack before they
+install the latest service pack.
+
+Note that a MySQL service pack is a complete replacement of an
+existing MySQL binary/executable and not just patches that are
+applied to an existing MySQL binary.
+
+In effect, the quarterly service packs replace MySQL Network's
+current "certified binaries".
+
+3.4 How does the Enterprise Server Service Pack Program Work?
+
+MySQL Enterprise will have two service pack programs:
+
+1. Rapid Update Program. This program serves customers who desire
+to stay as up to date as possible with releases of the MySQL
+Enterprise server. Service packs will be issued once a month for
+current Enterprise versions and be available for download on the
+MySQL Enterprise web site.
+
+2. Quarterly Service Pack Program. This program serves conservative
+customers who wish to stay current with fixes to the MySQL Enterprise
+server, but do not want to update their servers every month. This
+program provides cumulative, tested service packs that contain fixes
+to the MySQL Enterprise server, which are released every quarter.
+Note that quarterly service packs are cumulative so if a customer
+wishes to update, for example, twice a year, then they would simply
+take two service packs and apply them to their servers instead of
+four (assuming four quarterly service packs are released in a
+calendar year).
+
+3.5 How are Enterprise Service Packs Handled for MySQL Versions under
+Extended Support?
+
+Service Packs for releases of the MySQL Enterprise server that are
+under Extended Support will be handled in the following way:
+
+In accordance with the MySQL Lifecycle policy only security and S1
+issues will be considered for a Service pack resolution. This will
+apply to all releases under the Extended support umbrella regardless
+of their proximity to the current GA version of the product.
+
+There is no rapid update program for releases under Extended support.
+
+Service Packs for releases under Extended support will be released
+on a quarterly basis.
+
+A major release of the MySQL server is defined as the first two
+digits in the version number (e.g. 5.1).
+
+3.6 What is an Enterprise Hot-Fix?
+
+MySQL offers hot-fix support to MySQL Enterprise customers who
+encounter a known or undiscovered MySQL Enterprise server bug, not
+currently available in a current service pack, which causes a major
+business interruption. In this situation, MySQL AB will create a
+hot-fix patch for the customer, which will be delivered and applied
+to correct the reported issue.
+
+Note that a MySQL hot-fix is a complete replacement of an existing
+MySQL binary/executable and not just patches that are applied to
+an existing MySQL binary.
+
+3.7 How does the Enterprise Hot-Fix Program Work?
+
+MySQL AB's hot-fix process is designed to supply emergency database
+server patches for bugs and/or issues, which:
+
+Are validated by MySQL Support as being S1/S2 bugs.
+
+Are currently not addressed in an existing MySQL Enterprise server
+service pack.
+
+Are currently interrupting the normal business operation of a
+MySQL-based system.
+
+Currently have no workaround.
+
+There are two ways in which a hot-fix may be supplied to a MySQL customer:
+
+1. If the fix currently exists in a yet-to-be published MySQL service
+pack, MySQL Support will create a new MySQL binary that contains
+the needed patch using the unpublished service pack, which may
+include other bug fixes that may or may not be related to the
+reported problem.
+
+2. If the fix does not currently exist in any published or unpublished
+MySQL service pack, then MySQL Support will validate the bug and
+assign it to a MySQL developer for investigation. While MySQL cannot
+make time to delivery promises for unknown bugs, MySQL Support will
+update the customer as often as possible on the progress of the
+fix. When a fix is delivered from MySQL development, MySQL Support
+will create a new MySQL server binary that contains only that fix
+and deliver it to the customer.
+
+It should be understood that a hot-fix will likely always include
+other bug fixes that may or may not be related to the customer's
+hot-fix issue.
+
+Note that hot-fix support is available only to MySQL Enterprise
+Gold and Platinum customers.
+
+3.8 How are Enterprise Hot-Fixes Handled for MySQL Versions under
+Extended Support?
+
+Hot-fixes for releases of the MySQL Enterprise server that are under
+Extended Support will be handled in the following way:
+
+
+In accordance with the MySQL Lifecycle policy only security and S1
+issues will be considered for a hot fix resolution. This will apply
+to all releases under the Extended support umbrella regardless of
+their proximity to the current GA version of the product.
+
+Hot-fixes for releases under Extended support will be released on
+an as needed basis. A major release of the MySQL server is defined
+as the first two digits in the version number (e.g. 5.1).
+
+3.9 How often are bug fixes released to the Community?
+
+Formally speaking, bug fixes to the Community server are released
+on an "as-needed" basis, and are not scheduled or predictable in
+nature. They will, however, be frequent enough to ensure the community
+binaries do not become antiquated or contain crippling bugs that
+prohibit use of the Community server. Once a new major version of
+an Enterprise server ships, the current goal will be to have two
+drops of Community server binaries in a calendar year. These drops
+of community binaries will contain cumulative bug fixes and minor
+enhancements that community users have requested.
+
+Note that the number of community binary drops will be more frequent
+just after a new major release of the Community server. In the 2-3
+months it takes to reach enterprise quality in the Enterprise server,
+there will be as many binary drops of the Community server as it
+takes to reach an acceptable level of quality. Once a new major
+version of the Enterprise server ships, then a very infrequent
+binary drop schedule for community will be followed (with exceptions
+being made for critical security or data corruption issues).
+
+Bug fixes are always supplied in the MySQL source code and are
+always available; however binaries are not released as often as
+source updates.
+
+3.10 What would an example Enterprise/Community schedule look like?
+
+The following depicts an example of how a schedule may play out:
+
+[image]
+
+Note that the Enterprise binary drops contain bug fixes only, while
+the Community server drops contain cumulative bug fixes as well as
+minor enhancements.
+
+3.11 What is done to protect the quality of Enterprise Service pack
+releases?
+
+First, MySQL's internal QA area will be strengthened in the coming
+months to provide deeper coverage in finding and fixing critical
+server bugs.
+
+Each month, a rapid update is issued for MySQL Enterprise subscribers.
+Monthly updates are cumulative in nature. Before each quarterly
+service pack is issued, the prior month's rapid update release is
+'baked' into the customer base, with the goal being to have MySQL's
+cutting-edge customers find any regressions prior to issuing a
+quarterly service pack.
+
+In addition, this 'bake time' for each quarterly service pack will
+allow internal QA to thoroughly test the build candidate and locate
+any quality issues.
+
+Finally, it should be noted that MySQL Engineering requires two
+code reviewers (other than the developer that implemented a particular
+bug fix) to assess all submitted fixes, and automated checking tools
+(e.g. Valgrind) are also in play. The code review process used at
+MySQL is more stringent than many other shops, and this contributes
+to higher quality.
+
+With each issued quarterly service pack being handled this way, the
+quality of each release should be at a level of excellence that
+meets enterprise standards.
+
+3.12 How are critical bug fixes handled for both the Community and
+Enterprise Server?
+
+Critical security vulnerabilities that are discovered are corrected
+immediately, with new binaries being provided to both Enterprise
+customers and Community users, with a new software update bulletin
+being issued to Enterprise customers.
+
+The three main incidents that will trigger emergency fixes to both
+Enterprise and Community are:
+
+Critical security vulnerabilities.
+
+Data corruption on disk
+
+System crashing issues that affect most users.
+
+As an example, consider the following set of conditions:
+
+5.0.36a was the last issued Enterprise service pack
+
+5.0.37 was the last issued community binary
+
+A new critical security fix is needed
+
+In this case, the fix would be made with 5.0.36b being issued for
+Enterprise and 5.0.37a for Community.
+
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r3739 - in trunk: . refman-5.0 | paul | 25 Oct |
