openoffice-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [CONF] Apache OpenOffice Community > AOO 3.4.1 Reflection and Review
Date Sun, 23 Sep 2012 04:04:19 GMT
Space: Apache OpenOffice Community (
Page: AOO 3.4.1 Reflection and Review (

Edited by Shenfeng Liu:
AOO 3.4.1 was our second release and this page is intended to reflect and review the development
and release process towards this release to identify areas where we can improve things for
future releases. We are still learning and trying to improve and to streamline our development
and release process. The goal is to get more and more routine and to reduce the overhead for
all people who are involved.

Initial brainstorming of things that were recognized by people:

*What we did good:*
* Good triage process that ensured the most critical defects were caught in 3.4.1.
* Clear test report that give people an overview of the 3.4.1 quality status, and which scenario/component/configuration
was covered.
* Early preparation of the release notes and announcement, so that we can announce the release
as soon as the voting passed.

*what can be improved:*

* no working build bots, and not building the release branch
* too short time-frame between developer snapshots
* too less testing/review by the community on dev snapshots, start on RC only \-> Solution:
organize interim QA sessions, even far from RC phase, to detect problems early.
* RC were not communicated clearly. It would be far better for testers to name them "RC1",
"RC2" and so on, on the download page at least.
* do we need a more formal written down release check list that we can easy reuse for every
release. What is important here?
* RAT scan should be run earlier, or even with all buildbot builds
* We should do complete license/notice review even in a minor release where only a small number
of items have changed.  Why?  Because we may have missed something in the
previous release's review.
* There are tradeoff's in how frequently we issue new Release Candidates.  Doing
it frequently helps get the latest code out faster for final testing.  But frequent
RC's increases workload and churn on those who are building and uploading the RC's. 
Perhaps the way to make everyone happy would be to trigger RC's from a buildbot?
* Some of the tests were not completed in time for the final RC.  We should try to
coordinate this better, so all anticipated/required testing is done before RC is voted on.
* Need more detailed test plan/test cases to be published in advance. So that more volunteers
can participate.
* For RC testing, need to update the test progress daily or every other day, since usually
the voting will happen before the RC testing complete.
* A webpage/wiki to indicate RC clearly, not only on email thread.

Change your notification preferences:

View raw message