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
