As was proposed by Sogarth in this thread,
http://www.ppcgeeks.com/ppcgeeks-gro...hen-t2966.html, the members of PPCGeeks are embarking on a project to create a defect-free base ROM that will form the foundation of a web-based kitchen customization tool.
This scope of this thread is to propose a process for this project that all members are encouraged to comment upon and make suggestions.
This thread
is not for the debate of contents of any ROM, nor is it a place to request features. Those issues will be addressed in a thread early next week.
So, without further delay, here is a proposal for the process of developing a base ROM for the Apache PPC:
Goal:
The creation of a zero-defect ROM upon which any number of customizations can be applied. This may be expanded to create a number of base ROMs for different purposes.
Resources:
ROM Developers: We all know who the recognized gurus are in terms of ROM creation. Propose that all interested in serving as ROM developers on this project will submit their name by certain date. At that point, all members can vote in who will serve in this role. Propose that top 3 or 4 vote-getters serve as the ROM developers.
Analysts: These people will be responsible for writing the specs for each "release" of the ROM, with input from the site membership. I can volunteer to serve in this capacity. I propose that one more member be designated as an analyst.
QA Testers: These people will be responsible for testing each build before it is deemed "production ready". This should be open to anyone who wants to participate. The only stipulation is that all QA testers agree to submit defect reports in the format described below.
Project Manager: Responsible for creating and maintaing the release process. Other functions will the development of a build naming convention, creation of release notes, and the facilitation of communication between the above groups. I have already agreed to serve in this capacity. Another person will be needed to assist and serve as backup.
Definitions:
Beta: a build that has successfully passed QA testing and is available to the public. This build still may lack features and fixes, and therefore is not "to spec".
Build: A full compilation of the ROM, which should be fully functional.
Calendar: A set of milestones by which certain phases of a release are to be completed.
Release: A version of the ROM containing a collection of bug-fixes and enhancements. These are delivered in builds over the course of a release cycle.
Specification: A collection of requirements that will define the contents of a release. This would include bug-fixes and enhancements.
Process:
A release calendar is created that will define when releases are created and delivered. Propose that releases take place weekly, but on a two week cycle. This would mean, 2 days to write the specs, 5 days for ROM development, 2 days for QA testing, and 5 days for Beta testing. General release to the public would take place after the sucessful completion of Beta with no major defects.
Analysts will compile list of known issues through member input and searching the forum threads. These issues will be posted in a forum thread where the membership will be asked to rank their importance and severity. A final ranking will be compiled and submitted to the developers.
Developers will review the list of issues and provide an estimate of what can be done in the current release. Development of the ROM begins. Each developer will be responsible for specific pieces of work in a given release. Developers should do a preliminary test to ensure that their delivered bug-fix/enhancements function as intended before delivering to a build.
At the end of the development period, a build is delivered to the
QA testers who will focus on testing the changes made in that release.
Any defects/issues found in a particular build will be reported via a Defect Report (DR) thread in the Apache forum. All DRs must contain the following:
A detailed description of the problem, including what the tester was doing when the problem occured.
Device configuration, i.e., programs installed at the time the issue appeared.
Steps to repoduce the issue, if possible.
Severity. Propose that severity be broken down into 3 grades:
Showstopper: Any issue that results in the device locking up and needing a soft or hard reset to continue using it. Any issue where functionality of a feature is completely lost, i.e., no BT PAN. These defects must be addressed before a build can be put into Beta.
Medium: Issues which cause a program to not behave in a desired manner. These issues will be addressed in the next release.
Low: Issues that do not affect usability or program functionality, but are not expected. These would typically be display anomalies or artifacts. These issues will be addressed in a future release, but not necessarily the next one.
Beta and General Release: After a build has successfully passed QA, it will be delivered to the FTP site as a Beta. There, any member can download it for testing. The download should include a readme document with release notes and instructions for reporting defects. If defects are found during Beta, they may be incorporated into a build that again goes to QA, then refreshes Beta. If a Beta is sucessfully completed without any Showstopper DRs, it will be deemed the Final Version of that release and posted to the FTP site as such.
Needs:
1. A method of tracking changes delivered by the developers. Since developers will each be producing different pieces of the ROM, we need a respository where these changes will be stored until they are all integrated into a build. Any suggestions?
2. Access control. All pre-beta builds should be restricted for dowload to those that have agreed to function as developers, analysts, or QA testers. Propose using the PPCGeeks ftp site with passwords specific to this project.
Responsibilities:
Analysts: Compile and rank issues and write specs for all changes intended for a release.
Project Manager: Develops version naming convention, creates calendar, generates release notes.
Developers: Creates bug fixes and enhancements for the release, based on priorities and specs provided by the analysts.
QA Testers: Tests all changes delivered in a build, based on the specs.
Well, I think that's everything. If I think of more pieces, I'll revise this post as needed.
Please feel free to comment on the process, suggesting any changes by posting to this thread.
This thread will be open for discussion until a process is agreed upon by a majority of those posting to the thread.
Next step: A thread will soon be posted requesting volunteers for the various jobs within the project.
ADDED 2/21/2007, 2:31 PM, PST:
The above process will be applied to the development of the kitchen application, be it web based or app based. It is not yet decided whether or not the kithcen app will be developed in parallel with the ROM. That decision will be made in the near future.