(REVISED) PPCGeeks Unified ROM Project: Process Proposal

[Glossman]

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.

[luv2chill]

Awesome... my tired eyes can't manage to read it all now but I will pour through it tomorrow. Thank you (and Sogarth!) for all of your efforts to make this effort a well-oiled machine. We will all be better off for it!

[dannzeman]

All this planning and organization is making me very very excited! I can't wait for the morrow!

[schettj]

Version control would be nice, but unless you go with some web-based cvs it's not gonna work with the distributed development you're going to have here. I I don't think sourceforge is gonna work... hm Maybe it would.

We could check in the non-binary bits of the kitchen (no one should be patching binaries anyway) and that way we can track the changes/merge etc. I use CVS on my own kitchen (after getting burned myself making too many changes, and not having a known good version left )

So... that should not be a legal issue with MS (no MS code) - setting up the tree would be a bit of work, but you should then be able to check it out and overlay it on top of a kitchen with binaries.

[jamesus]

I can help out if needed. I would probably fit best in a QA tester role, but as I spend enough time on this site, I might be able to lend a hand in the analyst capacity.

Also, we might want to work with verizonguy based on this thread. Just a thought, since it seems as if he has a good start on some of the basics.

[Wideawake]

Very nice writeup and ideas guys. Wow it looks as if its time for me to dust of the ole ROM Tools. I think I may sticky this....

[jamesus]

Mike - as I read thru the threads of the custom ROM developers that have decided not to continue to develop due to the users hounding them, is there a way to make a closed forum for the develpoment of this? That way the users would not clutter the real work that can be accomplished here.

[Wideawake]

R U serious? I must have missed that damn this new job and training. I've been so busy. I can provide a private forum for development were only users of a group could post in it. Guys interested in firing this project back up? Anyone? Letme know here or PM.
~Mike

[MrHappy]

Just throwing my hat out there. I can help in any capacity you need. In the past I just used the Sprint official ROM as a base and customized it to fit my corporate standardization efforts but it is basicaly the same thing that you guys are doing.

Anyway, this is a GREAT idea, I am so happy to see some organized efforts here and hope that helmi, colonel, cokeman and all the others realize that we appreciate their efforts. Without them we would all still be using AKU 2.x!!

[naigaboy]

This is definitely a good idea. I can definitely make myself available to be a QA tester or analyst. This will definitely help put everyone on the same page and actually realise that we are all working to help each other. Good job Glossman.