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 Fri, 31 Aug 2007 14:09:44 GMT
Thanks for chipping in Jools,

Jools wrote:
> Sorry for any duplication in existing in other responses, not really had
> time to read the whole thread.
> 
> 
>> * What kind of development process do we need?  JIRA issues for
>>>    all changes?  code reviews?
> 
> 
> IMHO I would prefer that JIRA be used for all code changes. It gives us
> visibility of what is happening, and can be used as the index for a change
> log which should be produced for every release.

Agreed.

> Also, it might be that a developer in his own time developers a patch which
> is then submitted to the committers in private which would mean that the
> community would not have any visibility of the change in code.

I'm not sure whether I like the idea that patches are reviewed and
discussed in private (in the general case). I can imagine that some form
of criticism is better served by going private, but in most cases I like
the transparency when there is e.g. disagreement about some code
modifications.

> Code reviews should be part of the JIRA entry for the change. Valuable
> comments are made during code reviews, and these should be captured against
> the issues to which they pertain.

Personally I'm not that fond of having JIRA as the log for discussions.
I prefer to have (threaded) discussions on the mailing-list and
summarize the outcome in JIRA, either by copying a conclusion or
pointing to the archives. From what I've seen in the ASF JIRA it seems
to be a mixture though.

> There's also a testing issue here (for example, do you need to
>> supply tests?  if so, which framework or just unit tests).  This
>> is somewhat tied into:
>>> * What kind of testing do we need?
> 
> 
> 
> Every test should have a unit test. JUnit has served me well over the years.
> Every patch should have an attached unit test to prove out the patch.
> 
> Both the patch and the unit test must be reviewed.
> 
> A bug in the unit test is sometimes worse than a bug in the patch !

I hope Nigel of others familiar with the QA framework can shed some
light here, but in general I think we should continue with what is
already in place.

For many things I want to submit I fail to see how to write a proper
unit test (which can be entirely my fault). Most of these fixes were
indirectly tested by deployment of complete systems and observed for
strange/other behavior. It sounds kind of lame ... but e.g. writing a
test for a modification to ClassDep I consider too complex and expensive
versus seeing whether Seven and other services still correctly builds
(which touches everything).

> If I was to offer my advice, I'd say keep the committer pool fairly small
> and allow submissions in the form of a patch.
>
> A committer will then pick up the patch and review the change, and perhaps
> communicate with the patch author regarding any pertinent details.

In case of patches from non-committers I believe this is standard ASF
practice.

> Committer applies patch to the code base after reviews are complete.
> 
> Hope it helps.....

Any feelings with regard to code modifications of committers themselves,
i.e. RTC versus CTR. Does it make any difference in your willingness to
participate and becoming a committer.
-- 
Mark


Mime
View raw message