+1 (non-binding)
> On 25 May 2016, at 14:07, Ismael Juma <ism...@juma.me.uk> wrote:
>
> +1 (binding)
>
> I also think `log.cleaner.compaction.delay.ms` is clearer. As an aside, I
> did notice that the topic level config for `log.segment.delete.delay.ms`
> (mentioned by Ewen) is `file.delete.delay.ms`, which seems a bit
> inconsistent.
>
> Ismael
>
> On Wed, May 25, 2016 at 4:43 AM, Ewen Cheslack-Postava <e...@confluent.io>
> wrote:
>
>> +1 (binding)
>>
>> Agreed that the log.cleaner.compaction.delay.ms is probably a better name,
>> and consistent with log.segment.delete.delay.ms. Checked configs for other
>> suffixes that seemed reasonable and despite only appearing in that one
>> broker config, it seems the best match.
>>
>> -Ewen
>>
>> On Tue, May 24, 2016 at 8:16 PM, Jay Kreps <j...@confluent.io> wrote:
>>
>>> I'm +1 on the concept.
>>>
>>> As with others I think the core challenge is to express this in an
>>> intuitive way, and carry the same terminology across the docs, the
>> configs,
>>> and docstrings for the configs. Pictures would help.
>>>
>>> -Jay
>>>
>>> On Tue, May 24, 2016 at 6:54 PM, James Cheng <wushuja...@gmail.com>
>> wrote:
>>>
>>>> I'm not sure what are the rules for who is allowed to vote, but I'm:
>>>>
>>>> +1 (non-binding) on the proposal
>>>>
>>>> I agree that the "log.cleaner.min.compaction.lag.ms" name is a little
>>>> confusing.
>>>>
>>>> I like Becket's "log.cleaner.compaction.delay.ms", or something
>> similar.
>>>>
>>>> The KIP describes it as the portion of the topic "that will remain
>>>> uncompacted", so if you're open to alternate names:
>>>>
>>>> "log.cleaner.uncompacted.range.ms"
>>>> "log.cleaner.uncompacted.head.ms" (Except that I always get "log tail"
>>>> and "log head" mixed up...)
>>>> "log.cleaner.uncompacted.retention.ms" (Will it be confusing to have
>> the
>>>> word "retention" in non-time-based topics?)
>>>>
>>>> I just thought of something: what happens to the value of "
>>>> log.cleaner.delete.retention.ms"? Does it still have the same meaning
>> as
>>>> before? Does the timer start when log compaction happens (as it
>> currently
>>>> does), so in reality, tombstones will only be removed from the log some
>>>> time after (log.cleaner.min.compaction.lag.ms +
>>>> log.cleaner.delete.retention.ms)?
>>>>
>>>> -James
>>>>
>>>>> On May 24, 2016, at 5:46 PM, Becket Qin <becket....@gmail.com>
>> wrote:
>>>>>
>>>>> +1 (non-binding) on the proposal. Just a minor suggestion.
>>>>>
>>>>> I am wondering should we change the config name to "
>>>>> log.cleaner.compaction.delay.ms"? The first glance at the
>>> configuration
>>>>> name is a little confusing. I was thinking do we have a "max" lag?
>> And
>>> is
>>>>> this "lag" a bad thing?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jiangjie (Becket) Qin
>>>>>
>>>>>
>>>>> On Tue, May 24, 2016 at 4:21 PM, Gwen Shapira <g...@confluent.io>
>>> wrote:
>>>>>
>>>>>> +1 (binding)
>>>>>>
>>>>>> Thanks for responding to all my original concerns in the discussion
>>>> thread.
>>>>>>
>>>>>> On Tue, May 24, 2016 at 1:37 PM, Eric Wasserman <
>>>> eric.wasser...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I would like to begin voting on KIP-58 - Make Log Compaction Point
>>>>>>> Configurable
>>>>>>>
>>>>>>> KIP-58 is here: <
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-58+-+Make+Log+Compaction+Point+Configurable
>>>>>>>>
>>>>>>>
>>>>>>> The Jira ticket KAFKA-1981 Make log compaction point configurable
>>>>>>> is here: <https://issues.apache.org/jira/browse/KAFKA-1981>
>>>>>>>
>>>>>>> The original pull request is here: <
>>>>>>> https://github.com/apache/kafka/pull/1168>
>>>>>>> (this includes configurations for size and message count lags that
>>> will
>>>>>> be
>>>>>>> removed per discussion of KIP-58).
>>>>>>>
>>>>>>> The vote will run for 72 hours.
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Thanks,
>> Ewen
>>
