Thanks Peter, but code review guidelines are a different discussion.
I'm asking for commitment to feature design docs and test plans in
this thread.
Nige
On Nov 19, 2008, at 10:47 PM, Peter Veentjer wrote:
What about thread safety?
I see that the code base is very large and it is quite hard to analyse
because there is not much documentation if classes are used by
multiple threads/single thread/immutable
Other things I see are:
- eating up interrupted exceptions
- very coarse grained locking
- locking on objects you don't own and nested locking (both deadlock
prone)
- using non threadsafe collections in combination with custom locking
(doesn't need to be a bad thing, but not by default)
- java memory model problems (and they are hard to analyse because of
the lack of documentation)
These are a few of the things I have found so far.
I think these things can be simplified by adding them to the
guidelines.
On Thu, Nov 20, 2008 at 7:23 AM, Nigel Daley <[EMAIL PROTECTED]>
wrote:
Hadoop Committers,
The Hadoop project has grown to become a critical platform for many
companies. As we approach a 1.0 release (perhaps within the next 6
months)
I think it is time we adopt some more rigor around designing and
testing new
features.
As committers, we are already given a couple duties that relate to
quality.
From http://wiki.apache.org/hadoop/HowToCommit :
If a committer reviews a patch they've not authored, and believe
it to be
of sufficient quality, then they can commit the patch, otherwise
the patch
should be cancelled with a clear explanation for why it was
rejected.
...
Patches should be rejected which do not adhere to the guidelines in
http://wiki.apache.org/hadoop/HowToContribute and to the
http://wiki.apache.org/hadoop/CodeReviewChecklist. Committers
should always
be polite to contributors and try to instruct and encourage them to
contribute better patches.
These have been a good starting point, but I'd like to propose more
rigor.
I propose that before we commit issues marked as "New Feature",
they must
have:
1. a design doc attachment
2. a test plan attachment
(Templates to be provided for both)
I believe these 2 items will enhance the communication, design, and
quality
of our new features.
Are committers open to adopting these further guidelines?
Thanks,
Nige
