User:Chani/WayOfThePlasma/Categories/Policy: Difference between revisions
(no bug hiding) |
(quote from today's blog post) |
||
| Line 26: | Line 26: | ||
===Sources=== | ===Sources=== | ||
[http://mail.kde.org/pipermail/panel-devel/2008-February/006523.html panel-devel archive (2008-02)] | [http://mail.kde.org/pipermail/panel-devel/2008-February/006523.html panel-devel archive (2008-02)] | ||
==misc== | |||
===Original Text=== | |||
'''Aaron Seigo''' | |||
That's one of my favourite ways of working, actually: start with code that uses the API that should work but doesn't, get things to the point where they are working. The game is to do it without hacks, without API uglification and with as few new lines of code as possible. | |||
===Sources=== | |||
[http://aseigo.blogspot.com/2008/03/friday.html friday] | |||
Revision as of 01:34, 15 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.
Sources
Is it ok to make changes, even if they expose bugs in other parts of Plasma?
Conclusion
Absolutely. All known issues must be addressed. Visible bugs motivate people to fix the problem.
Original Text
Aaron Seigo
this is a good way to ensure that the issue is never addressed. by removing the obvious pain, you've swept the problem under the rug. it's not even a hard problem either, but this commit helps ensure the problem stays there.
please do not route around bugs like this in the future. =)
Sources
misc
Original Text
Aaron Seigo
That's one of my favourite ways of working, actually: start with code that uses the API that should work but doesn't, get things to the point where they are working. The game is to do it without hacks, without API uglification and with as few new lines of code as possible.