The Seamonkey Engineering Bible
The Book of Mozilla, 12:10And the beast shall come forth surrounded by a roiling cloud of vengeance. The house of the unbelievers shall be razed and they shall be scorched to the earth. Their tags shall blink until the end of days.
These things happen only if we treat engineers and the engineering process with respect and due diligence in every aspect of the development process.
High Speed, Large Scale, Cross Platform Development requires lots of communication and lots of hard work. Here are the things you must do to be an effective contributor and to keep other team members productive on the project. Remember, any problem introduced affects a wider and wider circle of participants on the project as time goes on.
Bug Analysis and Assignment
- add value to each bug before passing it to another engineer or tester
- get bugs with high quality data, in the hands of the right engineer as quickly and efficiently as possible.
- seek help from managers or peers to triage your bug list and do sanity checks on the priority in which you address bugs
- triage your bug list early and often; stay focused on the most important problems that affect you, and others working on the project, and using the product.
- When you check in a fix update the bug status and provide comments that will help to do extended testing on your changes.
Communicate and Plan at the pre-checkin gate (at this point your bustage only affects you)
- Get code reviews, and help from others to make your changes as clean as humanly possible
- develop a landing strategy for branches and individual changes
- merge to the tip, merge to the tip, merge to the tip, and when there are lots of people checking in code, merge to the tip.
- run general smoke tests and test your specific changes and know the state of the tree before you introduce your checkin, and after you complete your checkin.
- Line up help before you checkin
- If you're adding new files, make sure you make all the necessary changes
- send pre-checkin warning messages when your changes will affect others
- check in all files that make up your change (add new files first; remove old files last)
- send post checkin warning and confirmation messages that you have completed your checkin
- If the tree is red, don't checkin until it turns green.
If you absolutely need to checkin, and you're certain your changes
won't affect the current problems or cause additional bustage,
send mail to the hook and discuss your changes with the folks
that are working on current problems.
Communicate and Plan at the pre-verfication build gate (your bustage now affects you, folks on the hook, and anyone trying to join the hook)
- Once you checkin you have joined the hook and are responsible for the state of the tree.
- Watch tinderbox for build bustage from your changes and others
- Be highly available until the tree has a full cycle of green after you checkins are completed
- If your changes introduce bustage,
-
- acknowledge responsibility,
- estimate time to green,
- share your experience with others to avoid the same problem from reoccurring in the future,
- as tarah once wrote "repay others affected by your sins with wine, women and song."
- Be semi-available until the build verifications start the next morning
- Resolve conflicts in changes while your on the hook.
Communicate and Plan at the verification gate. (your bustage affects all of the above, plus the build team, plus qa acceptance testers)
- Be highly available when the build verifications complete, and be responsive when the build team is trying to diagnose problems with building or quick testing.
- Follow up on build issues and quick test blocking bugs and resolve as quickly as possible.
Communicate and Plan at the milestone gate (your bustage now affects all the above plus, the rest of qa, and 40,000 mozilla testers, and a 1500 milestone tarball downloaders)
- Watch talkback data reports for crash bugs in your area.
- Follow the newsgroups for patches, and suggestions to make your module better...