User:Chani/WayOfThePlasma/Categories/Policy

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

panel-devel archive (2008-02)

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

panel-devel archive (2008-02)

I want an option to turn this bug off

Conclusion

Issues should be resolved, not hidden.

Original Text

Aaron Seigo

those kinds of options are there *only* to take away the pain/annoyance/whatever of a feature (or mis-feature, depending on the case). instead, if one works on tooling that feature into something better .. one gets a better tool and doesn't add yet more to the configuration load.

and yes, high configuration load does have a very negative impact on the user experience.

worse, if we let you turn this off now .. where will we get feedback on what we do with it so that we can figure out when/how it is more acceptable? no, you'll just all turn it off and never look back at it again. i'd rather try and *fix* issues rather than cover them up, with the result being a mess of code paths and half finished features.

moreover, as a feature in development, i'm very against making the implementation yet more complicated than necessary until we have some of the other fundamentals in place.

Sources

b.k.o comment

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

friday