Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # dev >> cleanup and subjective patches

Copy link to this message
cleanup and subjective patches
i know we have discussed this in the past, but we never really came to
a consensus or policy, so i'd like to reopen the discussion on cleanup
and subjective patches.

currently there are 7 jiras for cleanup issues, 6 of them marked as
major. the problem with cleanup or subjective patches is that they
take committer time, they can collide with other patches (or patches
in progress), and they can introduce new bugs. i know we have
discussed this in the past, but i think it would be good to establish
a policy of rejecting such patches. this isn't to say that the code
looks nice or is clean as it is, it's just that we want to avoid
disrupting a code base that people count on.

that is my perspective. it would be good to come to an agreement on a
policy so that we can deal with such patches quickly rather than drag
things out for both the contributor and the committer. right now, we
have a patch that fixes a memory leak and a patch that switches
integer constants to enum and they are both marked as major. another
minor patch fixes how the log cleanups are done. i think we should be
focusing on the leaks and logs. perhaps in the future when we don't
have such a backlog of changes, we can reevaluate the policy, but
right now i would like to make "code cleanup not a bug fix or
enhancement" a reason for patch rejection.

other thoughts?