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 > >
