On 01/30/2014 07:32 AM, Duncan Mac-Vicar P. wrote:

I fully agree with you that this is not acceptable.

Now, I think your diagnostic is IMHO neither fair or correct. This does
not have to do with the "community contributions" but with the setup of
the project itself.
We sometimes have sent patches that are very strictly reviewed,
sometimes needing change multiple times to get a reviewer happy.

Then next day our internal testsuite fails only to realize that someone
with direct commit access did a big refactoring and committed very
broken code in a big patch that was not reviewed by anyone and which
quality was also obviously not the best. We asked ourselves, what is the
point of reviewing "some of them"?. Not only code but also design
decisions and way of approaching solutions.

Sometimes this happens with our own patches, depending on the reviewer,
they may get committed faster.

The setup of the review process is broken.

- All code should be committed in similar units (features/branches)
- All code should be able to be reviewed and vetoed by everyone

OpenStack has this model working quite successfully. Every patch is
reviewed with +1, and they need a certain amounts of ACKS to get
committed. Everyone can review and people learn in the process, and it
is a great source of inspiration for other projects.

For what it's worth I agree with Duncan. I think that having a consistent process requiring multiple reviews for all changes could only improve code quality and make Spacewalk more accessible to community contributors. The process Duncan describes is very common among modern open source projects and seems to work well.

-Stpehen

_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Reply via email to