[Sugar-devel] code review (was Re: buddy tags)

[Tomeu Vizoso]

On Mon, Aug 3, 2009 at 21:39, Gary C Martin<gary at 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