Confirmed users
2,615
edits
Calendar:Development Strategies: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 4: | Line 4: | ||
* Too much time is spent blocked, waiting for input from reviewers/owners | * Too much time is spent blocked, waiting for input from reviewers/owners | ||
* Patches are requiring too many revisions and partial re-writes, causing both frustration and wasted time | * Patches are requiring too many revisions and partial re-writes, causing both frustration and wasted time | ||
The biggest piece is that by accepting the cost of communicating | The biggest piece is that by accepting the cost of communicating | ||
| Line 28: | Line 25: | ||
Pretty much everyone I've ever seen be productive and successful in | Pretty much everyone I've ever seen be productive and successful in | ||
the Mozilla development environment has done so by deeply embracing a couple of key strategies. I think the above guidelines are only really going to help us if we | the Mozilla development environment has done so by deeply embracing a couple of key strategies. I think the above guidelines are only really going to help us if we do too. Specifically: | ||
*; multiplex work on multiple bugs | *; multiplex work on multiple bugs : The key thing here is that whenever the existing bugs you're working on are waiting for feedback, go find another bug. There are various strategies that help make this managable, including: | ||
** pick another bug in a non-overlapping area of code | ** pick another bug in a non-overlapping area of code | ||
** store in-progress work as a patch by using "cvs diff" with "patch -R" | ** store in-progress work as a patch by using "cvs diff" with "patch -R" | ||
** use multiple objdirs | ** use multiple objdirs | ||
** use multiple source trees | ** use multiple source trees | ||
** see also point 5 of [http://www.mozilla.org/hacking/development-strategies.html the Development Strategies document]. | |||
* split work into manageable pieces | *; split work into manageable pieces : This is critical, because difficulty to review and give feedback often scales extremely non-linearly with patch size. Points 7, 8, and 12 of the [http://www.mozilla.org/hacking/new-features.html Developing New Mozilla Features page] address this in great detail. | ||