Trunk is in a weird state right now, with half the classes moved and half not, and this work seems to be destabilizing. I think it would have made more sense for
HDFS-6200 to have been done in a branch.
The value of doing this work in trunk might be under-appreciated. Moving the code in trunk opens up subsequent opportunities to further clean up the code, such as removing excessing dependency (
HDFS-6564), and cleaning up checkstyle errors ( HDFS-8620). If the work had been done in a separate branch, due to the scope of changes the main focus was to keep the branch in sync, making further clean up difficult, if not impossible.
Given the nature of refactoring and the scope of changes, stability is definitely a concern and we try to establish some policy up front. The policy is to (1) zero new features in these patches, (2) separating the further clean ups from the patches that move the code to the hadoop-hdfs-client module. The policy should be able to keep the risks of destablization low and to allow issues quickly to be addressed.