On 10/31/2013 10:36 PM, Jeremy Stanley wrote:
Reviewing and contributing unit tests are the developer activities we
have for addressing quality. I think the issue here is how we as a
community make sure there is balance between these activities and raw
feature (and bug) contribution, given that most developers most enjoy
hacking away, myself included. In a corporate software project, this
balance would be enforced by one or all of:
On 2013-10-31 22:45:56 +0000 (+0000), Romain Hardouin wrote:
Adding a message for new comers is a good idea.
I am a new Horizon contributor, some of my fixes have been merged
(thanks to Upstream University :-) and reviewers of course) but I
still hesitate to do code review. To my mind, it is reserved to
"known" developpers whose opinion matters...
Not at all. One of the best ways to become "known" within the
community is to review code and provide good recommendations. Even
something as simple as spotting typographical errors in changes to
user-facing messages and documentation provides value. The more
problems you can find (and ultimately help prevent) in a change, the
faster your reputation will grow.
As has been said many times already, OpenStack does not lack
developers... it lacks reviewers.
1. Slowing down development
2. Providing more qa resources, including requiring developers to write
3. Knowingly accepting quality risk in exchange for some
As an open source community we cannot do some of these things. But lack
of reviewers effectively slows down development, and we can strive for
the scalability of quality that comes from developers writing unit
tests. My first contribution to swift was rejected until I enhanced the
test infrastructure even though what I did was similar to other things
that were not really being tested.
We should be nice about it, and spend a little extra effort in helping
new contributors get into the swing of writing unit tests, but the
review gate is the only real mechanism we have for making sure we have
sufficient coverage to keep the code base maintainable by others in the
future. I really like Rob's list because it leads down a path of better
shared understanding of how lax/lenient reviewers should be about this.
OpenStack-dev mailing list