On Mon, Aug 3, 2009 at 21:39, Gary C Martin<g...@garycmartin.com> wrote: [snip] > > Though I'm not sure I have the stamina to get past your code reviews for any > original coding. It's hard enough to get a bug fix r+ accepted when making a > minimal tweak to existing code! ;-)
I'm not sure what I can say about this. I see how code contributors to Sugar can find a pain these code reviews and we need to improve the process anyway. I will work on documenting this better, but it's also true that if people had followed what is already in the wiki, it would had been much less painful for everyone (yes, it's also hard for the reviewer). http://wiki.sugarlabs.org/go/Development_Team/CodeReview But I guess knowing in advance how the code is expected to be written is just half of the problem, the other half is understanding why it is so important. And I'm not sure how we are going to build that understanding as long as it's only Simon and me the ones spending several months per year debugging and fixing bugs. Seems like only when you are responsible for the quality of a module and thus take on the so tedious task of debugging, you are going to appreciate the importance of coherent code style and sound class design. If we are going to considerate the possibility of relaxing the requirements for new code, I would like to note the of the dozen or so other projects I have sent patches to, only two didn't reviewed code nor enforced a particular code style. And I can tell you that debugging those two projects was much harder, taking more time and energy. I would never volunteer to maintain any of those. For the other projects, I had to work hard to make sure that my patch would fit the rest of the codebase and even then my patches were scrutinized and had to rework them several times. But I learned a lot and gained a new perspective on how code should be contributed. What can we do here if we want our code to be as bug free as possible and also make it easier for non-maintainers to contribute new code? A first step is to have more maintainers, Simon and me are already holding maintenance of too many modules. But then, what will happen when a bad decision is taken? Do we have today a community that will voice their concerns when a decision will hurt actual users? Or only after one year when that release is started to be deployed we'll hear that "Sugar sucks"? Thoughts? Thanks, Tomeu _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel