Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

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


Copy link to this message
-
Re: cleanup and subjective patches
deprioritizing them doesn't help because the patches themselves bit
rot. shortly they will not apply and then they will be worthless. the
poor contributor would then be left with the task of maintaining a
patch that would never commit.

note also that i'm not saying that the code should not be cleaned.
it's just that it should be done in conjunction with an enhancement or
bug fix.

ben

On Mon, Oct 31, 2011 at 2:10 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> 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 <[EMAIL PROTECTED]> 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
>>
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB