summaryrefslogtreecommitdiff
path: root/X11R68PostPartumNotes.mdwn
diff options
context:
space:
mode:
authorAlanCoopersmith <AlanCoopersmith@web>2013-09-15 11:46:20 -0700
committerxorg <iki-xorg@freedesktop.org>2013-09-15 11:46:20 -0700
commit086ea5308b02e303f30e0668eacf95b12eab7e9b (patch)
treefc9ad89f0fe6a3ae47e6d1e6a3b97bee7d5f75ba /X11R68PostPartumNotes.mdwn
parentb1ff210d2d463ea1a20016b1874912fea8010c70 (diff)
fix formatting after moin->iki conversion
Diffstat (limited to 'X11R68PostPartumNotes.mdwn')
-rw-r--r--X11R68PostPartumNotes.mdwn13
1 files changed, 9 insertions, 4 deletions
diff --git a/X11R68PostPartumNotes.mdwn b/X11R68PostPartumNotes.mdwn
index e106e8bb..7b2b3a3f 100644
--- a/X11R68PostPartumNotes.mdwn
+++ b/X11R68PostPartumNotes.mdwn
@@ -1,8 +1,6 @@
-
-
# X.Org Foundation 6.8 release postpartum discussion notes
-[[!toc ]]
+[[!toc startlevel=2]]
## Introduction
@@ -23,6 +21,7 @@ The initial deadline for the release left us with a very tight schedule, which h
* The number of new features added in this release was significant; however, most (if not all) had significant testing outside of the X.Org CVS tree before they were merged in. The majority of the remaining testing and bug fixing for these features were due to interactions they had with other new components.
* It was challenging to keep people working on the features and bugs in order to meet the deadlines. Gentle pressure was applied in most cases to help motivate people on the critical paths. This will likely always be an issue for the release manager.
* Because the release cycle was compressed, it was not difficult to keep people focused on the release. However, if the release cycle was longer, this will likely become a problem.
+
The schedule was broken down into three phases: adding new features, fixing bugs and updating documentation. The deadlines were set approximately two weeks apart for each phase in order for the release to be completed by the initial target date.
During the first phase, the tree was open to adding new features, fixing bugs and updating documentation. The primary responsibility was setting up the initial wiki pages to describe the release plan and status, making sure that the community members were aware of the release schedule and coordinating with the authors of the new code to make sure that everything was checked in before the feature freeze deadline. This phase went smoothly with only a small amount of additional work being required to encourage a few of the committers to have their code checked in before the deadline.
@@ -35,6 +34,7 @@ After the feature freeze, the work was limited to fixing bugs and updating docum
* Reviewing and checking in fixes
* Resolving conflicts
* Encouraging testing (see testing section below)
+
Several suggestions were made by the release wranglers to help with fixing bugs. The most important of which was the release bug, which is a commonly practiced method of managing a release. Bugs that were considered serious enough to hold up (i.e., block) the release should be marked as blocking the release bug. Bugzilla allows the release manager to list the dependency tree of all bugs that block the release. While there were several attempts to explain how this worked, there was still some confusion. For future releases, it should probably be explicitly explained on the release and status pages.
The release wranglers met several times per week -- usually Monday, Wednesday and Friday mornings -- to focus on the blocker bugs and any issues that had come up during the previous few days. During these meetings, the release manager asked for (and usually got) volunteers to work on certain bugs. The remaining bugs were left to the release manager to investigate and resolve. These meetings were invaluable to the release manager.
@@ -105,6 +105,7 @@ The documentation needed to be updated in several places. First, the release nu
* xc/doc/specs/i18n/Framework.ms
* xc/doc/specs/i18n/LocaleDB.ms
* xc/doc/specs/i18n/Trans.ms
+
Note that the documentation listed above is current as of the 6.8 release, and might change in the future.
The documentation in the xc/programs/Xserver/hw/xfree86/doc directory also needed to be updated. This documentation was built from the sgml files in the sgml subdir. The README, BUILD and RELNOTES sgml files will probably need to be updated with every release. The other files should be updated by their respective maintainers as needed. One special file, defs.ent, contains the macro definitions for the current and previous releases, and it was updated. Next, the old XFree86 doctools were required to build the sgml documentation. A few patches were required to build the tools (thanks to Soeren). Egbert added a README.build-docs file that describes what is needed to build and update the docs in the source tree.
@@ -114,6 +115,7 @@ Once the documentation was complete, the last steps to finish the development ph
* Set the final version number and release date in the config/cf/xorg.cf and config/cf/cygwin.cf files
* Tag the tree with the release tag, XORG-6_8_0
* Create the release branch, XORG-6_8-branch
+
It was noted in an earlier release wranglers call that the branch could have been created much earlier in the release. Due to the compressed time schedule, it was decided to hold off creating the branch until very late to keep people focused on the release, instead of on new development. This should be reevaluated for future releases.
Additional discussion points:
@@ -133,7 +135,8 @@ First, we determined that, given the scheduling constraints, it would not be pos
Next, we proposed a set of tests to be run on those platforms. The list included build, install, conformance and run test categories, and we outlined what was required to pass each test category. The tests as well as the platforms were organized into a matrix and was added to the freedesktop wiki:
- * [[http://wiki.x.org/wiki/X11R68ReleaseStatus|http://wiki.x.org/wiki/X11R68ReleaseStatus]]
+ * [[X11R68ReleaseStatus]]
+
On that page, the test matrix was included and instructions were given for running each of the tests. Initially the instructions were quite sparse, but as more people ran the tests, they were expanded and improved.
In the test matrix, the first three columns of each row defined one platform to be tested, and the last four columns displayed the state of the testing on that platform. Entries were labeled with the release candidate version that was tested and were given a green background if the test passed or a red background if the test failed (or had not yet been tested).
@@ -147,6 +150,7 @@ Names responsible for testing (or gathering the test information) were put into
* By the time the testing had begun, it quickly became clear that there were problems with the tests, which had to be addressed before any testing could truly begin. These problems were worked out within a few days, but the delay caused confusion and slowed down the testing process, and ultimately led to the release being delayed.
* There was also confusion about exactly which tests could be run on each platform. Certain tests could only be run on Linux systems, and comparable tests were not investigated for other platforms.
* The X test suite used was chosen for expediency and ease of use. It was not necessarily the best one available.
+
The initial goal for testing was to fill in the entire test matrix before the final release. However, it became clear to the release wranglers during the release cycle that the test matrix would not be completely filled, so the goal was changed to fill in as much of the matrix as possible before the release.
As noted above, testing is a very time consuming process and certain tests lend themselves to automation. Many people do not have the extra test machines required to do run tests; however, for those that do, automating the test process would certainly make it more likely that testing would be done. One key tool that automated part of the testing procedure was tinderbox. It allowed us to quickly notice when recent check-ins broke the build process. During many of the release wranglers calls, tinderbox and related tools were discussed, and it was generally agreed that these tools should be explored further to help automate as many of the tests as possible.
@@ -213,4 +217,5 @@ Discussion points:
* How much ahead of time does the press release need to be sent to the appropriate press outlets in order for it to be released at a specific time (i.e., the time that the embargo is lifted)?
* What other mirror sites are available? What should be done to coordinate with them to make the release available on their sites as soon as possible after the announcement?
+
-- [[KevinMartin|http://wiki.freedesktop.org/wiki/KevinMartin]] - 29 Sep 2004 (updated for [[MoinMoin|MoinMoin]] 02 Mar 2005)