正在阅读：Mozilla开发组的开发策略(英文)Mozilla开发组的开发策略(英文)

2004-02-14 09:34 出处：PConline原创作者：Seth Spitzer & Alec Flett 责任编辑：zwg

5) work on multiple bugs in parallel You should be working on the most important bugs first. But those might be difficult bugs (hard to reproduce crashers, big rewrites for performance, etc.) which can take several days or weeks to complete, plus the time for reviews. In your other trees, work on smaller, easier bugs. Pick bugs that won't cause conflicts with your work in your primary tree. Pick bugs that should only take you a few hours or a day to fix. In theory, fixes for these bugs will be quick to review. If you have problems finding smaller, easier bugs to work on, start by looking for crashers. Maybe the problem can be turned into an assert, or fixed altogether. You can use talkback queries or bugzilla queries to find crashers. Also, look for mail window front-end bugs. We've got a lot of UI polish bugs that can be fixed with a small .dtd, .js, .properties or .xul change. In addition, look for problems in existing code. Find and fix string usage problems. Find and fix bad XPCOM macro usage. Switch some code over to nsCOMPtrs. Look for XXX or TODO in the code, verify the code still needs fixing, and fix it. 6) smaller patches get reviewed faster If you find that you spend a lot of time waiting for reviews, keep in mind that patch size is not linear to time to review. A twenty line patch doesn't take twice as long to review as a ten line patch, it usually takes more time. If you can divide and conquer what you are working on into smaller chunks, you will find you'll get faster reviews. Of course, not everything can be divided up. And, shorter fixes aren't better than longer ones. Having parallel trees should allow you to work on other items, while you are awaiting reviews. 7) get advice before working on a patch or feature before you start working on it, instead of after If you are blocked, or stumped as to what to work on, talk to a lead sooner rather than later. Most likely they will have a bug they can hand off to you, or they can help get you unblocked. Since they are going to be reviewing your code later, run your plan of attack by them first. It's better to have an idea rejected, than a big patch.