river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: development process
Date Wed, 29 Aug 2007 06:37:04 GMT
Jim Hurley wrote:
> (Note: we made good progress on the first question... but
> just leaving room for anyone else to add in before I summarized).
> Meanwhile... on to the next)
> 
> As we continue discussing the "AR1" release questions/tasks...
> here's the next:
> 
>> * What kind of development process do we need?  JIRA issues for
>>    all changes?  code reviews?

I would say JIRA issues for all changes, except for the really trivial
stuff (like fixing a typo while working on another issue, but I believe
people are smart enough to get a feeling what belongs in JIRA).

> So, regarding development process -- what do you think?
> In looking around, I didn't see a norm for things (for example,
> not sure if projects use JIRA for everything).  We've used code
> reviews inside our group at Sun for the starter kit, and it's proved
> immensely valuable.  I'd vote to continue it - both as a quality
> measure as well as a way to get more people involved and
> knowledgeable about the different pieces of code.

Code review is indeed immensely valuable and rather essential especially
for those things that are extremely hard to test properly, such as
concurrency related code or for which it is extremely hard to get the
right conditions into place and I think that a lot of the current
codebase falls into this category.

As all code changes are subject to voting and require 3 +1 votes and no
veto I expect people to give their vote only when they looked into it
sufficiently to backup their opinion.

So if we decide to have a Review-Then-Commit policy
(http://apache.org/foundation/glossary.html#ReviewThenCommit) I think
code review is in place by default, if we decide to go for
Commit-Then-Review
(http://apache.org/foundation/glossary.html#CommitThenReview) and you
want to be assured that all code finally checked in is reviewed by
somebody else we need to come up with a procedure that takes care of that.

I'm inclined to a Review-Then-Commit policy although a 3 days period
before being able to check-in feels like a very long time in some cases,
although completely understandable from the perspective to give people
time to look into it. Another risk is that 'commit starvation' occurs
when there are no 3 committers finding the time to look into it and as a
result there won't be any 3 +1's required to be allowed to check-in the
code.

Maybe there are cases and/or parts of the codebase where
Commit-Then-Review is more appropriate (website updates e.g.) and I have
no problem with applying them both.
-- 
Mark



Mime
View raw message