Release QA Tracking Tool
Original Proposal by Andrea Pescetti - please discuss below rather than editing this box.
I will realize a new web-based tool for tracking QA of localized OpenOffice.org builds. It will feature clear, informative and attractive screens for the general public, easy management and updating, IssueZilla integration, notification by e-mail and RSS feeds and easy extensibility.
The tool will help the OOo community during all steps of the QA process for localized builds. The focus will be on having a system, easy to use and maintain, for the QA volunteers and on guaranteeing fast and reliable diffusion of information to the general public.
The tool will automatically maintain a main page, which summarizes the status of every build, and specialized subpages. It will assist in every step of the QA process as follows.
- Localized builds are made available by known providers via the tool
- Links to the (untested) builds appear on the main page
- Interested Native-Lang QA Leads are informed by e-mail and RSS
- A Native-Lang QA Lead notifies beginning of tests to the tool
- The build appears as "In QA" on the main page
- If possible, links to the suitable TCM pages are provided (to authorized users and for supported locales) to track QA progress
- Optionally, a closing date for tests can be specified and shown
Step 3-A (if the build passes tests):
- The QA lead notifies success to the tool
- The build appears as "QA passed" on the main page
- The QA lead, assisted by the tool with a pre-filled IssueZilla template, notifies success and asks for distribution to mirrors
- A notice appears in RSS feeds to inform about approval
- When the distribution issue is closed, the QA lead notifies the tool
- The build appears as "Released" on the main page
- Download link is optionally changed
- E-mail notifications and RSS feeds inform of the release availability
Step 3-B (if the build fails tests):
- The QA lead notifies failure to the tool
- The build appears as "QA Failed" on the main page
- Links to the blocking (global or localization) issues are shown on the page
- A notice appears in RSS feeds
Main page for the general public:
- A table will summarize all information about builds for each language and platform
- Default sorting will be by language (English first, then all languages for which a localized build is available, then all other languages); other sorting options will be available
- Subpages will be available for the single builds; they will contain more verbose descriptions and more detailed information
There will be three types of users:
- ADM, Administrators: add languages/platforms, manage users
- BPR, Build providers: provide localized binaries for testing
- QAL, Native-Lang QA Leads: one or more per language, report test results
ADMs have access to the Administrative interface, providing:
- User management: ADMs can add/modify/remove any user
- Language management: ADMs can add new language name/code pairs
- Platform management: ADMs can add new platforms
- Moreover, an ADM has all BPR and QAL privileges
BPRs have access to the Build submission interface:
- BPRs can inform about builds in progress and set the "Build in progress" status for platform/language pairs
- When builds are ready, BPRs publish them through the tool
- If a new build is submitted and an older one is still in QA for the same language and platform, both builds will be displayed on the main page
- Every time a new English build is submitted, all BPRs are notified through the usual channels (e-mail, RSS feeds)
- The tool supports simultaneous submission of many builds for the same platform via wildcards or heuristics
- Optionally, mirror sites for the same build can be specified
QALs manage the rest of the process:
- QALs can add new QALs for their language, in order to delegate work
- QALs interact with the tool in all steps of the process
Technical details and requirements
- Authentication: If at all possible, users should be able to login via their OpenOffice.org website/IssueZilla account, as it happens in EIS (Environment Information System). This will also make Step 3 (opening distribution release issue) smoother. So "adding a new user to the tool" will actually mean "granting access to the tool to an existing OOo account".
- Technology: The tool will be written in PHP and will operate on a MySQL database.
- License: I would like to make the tool available under the GPL license.
Development will take about 15 weeks. The period will be divided as follows:
- In week 1: Get suggestions (ml/wiki) from people doing OOo 2.0.3 QA
- By week 3: Basic setup; see if common authentication is feasible
- By week 5: Administrative interface completed
- By week 7: Notification system (e-mail, RSS feeds) completed
- By week 10: Interface for Build Providers completed
- By week 13: Pages and interface for QALs completed; public testing
- By week 15: Layout improvements; bug fixing
I would like to know whether the project above suits the needs of the community, based on the experience of people involved in OOo QA. Adjustments to the project can be done if necessary.
If some QA teams would like to have early access to the tool, and to help with testing, they are welcome to contact the developer (see below).
How to follow development
A development Blog and a CVS repository will be set up shortly, as well as a web page containing mock-ups of the tool in development.
Contacts and Acknowledgements
- Andrea Pescetti, pescetti -at- openoffice.org
- André Schnabel, (Andre.Schnabel at gmx.net) will mentor the project.
- Mailing list
- The relevant mailing list is dev -at- qa.openoffice.org and all announcements will be sent on that list. You can browse the archives.
- The project was originally submitted as a proposal for the Google-sponsored Summer of Code initiative, but will be supported independently.