User:Chani/WayOfThePlasma/Categories/Policy: Difference between revisions
(why peer-review) |
m (using a list was a stupid idea) |
||
| Line 6: | Line 6: | ||
'''Aaron Seigo''' | '''Aaron Seigo''' | ||
<tt>now, last week saw many unreviewed commits that actually resulted in rather unecessary issues in the code base; (...) people have a tendency to fall back to methods that got us kicker and kdesktop (namely: really useful programs that did a ton of a stuff but were at a point where they hit a brick wall as far as being able to take them further).</tt> | |||
<tt>free-for-all does have a very negative impact on the code base. we tried that, and we moved to peer review because of what that resulted in.</tt> | |||
===Sources=== | ===Sources=== | ||
[http://mail.kde.org/pipermail/panel-devel/2008-February/006569.html panel-devel archive (2008-02)] | [http://mail.kde.org/pipermail/panel-devel/2008-February/006569.html panel-devel archive (2008-02)] | ||
Revision as of 20:02, 13 March 2008
Why must patches be peer-reviewed before they can be commited?
Conclusion
It is hard for new contributers to see all possible consequences of the changes they introduce. This has lead to long-term issues in earlier projects.
Original Text
Aaron Seigo
now, last week saw many unreviewed commits that actually resulted in rather unecessary issues in the code base; (...) people have a tendency to fall back to methods that got us kicker and kdesktop (namely: really useful programs that did a ton of a stuff but were at a point where they hit a brick wall as far as being able to take them further).
free-for-all does have a very negative impact on the code base. we tried that, and we moved to peer review because of what that resulted in.