This is a bold position. I can't disagree with the prioritization. And I can't disagree with the risk assessment (see https://issues.apache.org/jira/browse/ZOOKEEPER-1271for an example where my fixing one bug caused another).
But summarily rejecting all such changes seems a bit harsh. I think it is fine to downgrade the severity on all cleanup JIRA's. Rejecting them out of hand is a good way to guarantee (in my opinion) that ZK eventually dies of bit-rot. On Mon, Oct 31, 2011 at 2:06 PM, Benjamin Reed <br...@apache.org> wrote: > 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? > > thanx > ben >
