Yes, people in the community are allowed to vote on keeping features.

Details:
According to the Apache voting process there are binding and non-binding votes. 
 The binding votes are from PMC members and are the ones that count officially. 
 However, not officially, votes from the community hold a lot of weight.

https://www.apache.org/foundation/voting.html 
<https://www.apache.org/foundation/voting.html>

-Bryan




> On Aug 22, 2016, at 3:07 PM, Shrihari Kalkar <shrihari.kal...@riverbed.com> 
> wrote:
> 
> Okay, I would like to vote for keeping this feature if I am allowed to :)
> -0
> Thanks,
> Shrihari
> On 8/22/16, 2:35 PM, "Bryan Call" <bc...@apache.org> wrote:
> 
>> There are a few bugs that are opened around log collation.  However, I
>> don¹t think any are major issues.  Your feedback is very important in the
>> decision on whether to keep this feature.
>> 
>> Simple search on bugs with ³collation² in them:
>> https://issues.apache.org/jira/browse/TS-966?filter=12338253&jql=project%2
>> 0%3D%20TS%20AND%20resolution%20%3D%20Unresolved%20AND%20text%20~%20%22coll
>> ation%22%20ORDER%20BY%20status%20DESC%2C%20updatedDate%20DESC
>> <https://issues.apache.org/jira/browse/TS-966?filter=12338253&jql=project%
>> 20=%20TS%20AND%20resolution%20=%20Unresolved%20AND%20text%20~%20%22collati
>> on%22%20ORDER%20BY%20status%20DESC,%20updatedDate%20DESC>
>> 
>> -Bryan
>> 
>> 
>> 
>> 
>>> On Aug 22, 2016, at 1:55 PM, Shrihari Kalkar
>>> <shrihari.kal...@riverbed.com> wrote:
>>> 
>>> Hey guys,
>>> I really like this feature and we use it quite often. We tried using
>>> log collation with pipes but somehow we couldn't get that to work
>>> reliably. It would be good to have this around. Have we seen many bugs
>>> in this area of code? Is it possible to keep this feature around?
>>> Thanks,
>>> Shrihari
>>> 
>>> 
>>> From: Phil Sorber <sor...@apache.org <mailto:sor...@apache.org>>
>>> Reply-To: "us...@trafficserver.apache.org
>>> <mailto:us...@trafficserver.apache.org>" <us...@trafficserver.apache.org
>>> <mailto:us...@trafficserver.apache.org>>
>>> Date: Monday, August 22, 2016 at 11:29 AM
>>> To: "us...@trafficserver.apache.org
>>> <mailto:us...@trafficserver.apache.org>" <us...@trafficserver.apache.org
>>> <mailto:us...@trafficserver.apache.org>>, "dev@trafficserver.apache.org
>>> <mailto:dev@trafficserver.apache.org>" <dev@trafficserver.apache.org
>>> <mailto:dev@trafficserver.apache.org>>
>>> Subject: Re: [PROPOSAL] Removing logs collation support in 7.0.0
>>> 
>>>> +0
>>>> 
>>>> On Sat, Aug 20, 2016 at 8:06 PM James Peach <jpe...@apache.org
>>>> <mailto:jpe...@apache.org>> wrote:
>>>>> 
>>>>>> On Aug 19, 2016, at 3:32 PM, Bryan Call <bryan.c...@gmail.com
>>>>> <mailto:bryan.c...@gmail.com>> wrote:
>>>>>> 
>>>>>> There are a few features we are looking to remove in the ATS 7.0.0
>>>>> release.  If you are using these features and require them, please
>>>>> respond to this email.  We also need to have people that are willing
>>>>> to invest time and fix some of the bugs for these features.   Your
>>>>> feedback is very important!
>>>>>> 
>>>>>> An alternative solution to log collation is to log to a pipe and
>>>>> have an external process take care of log collation.  Here is the
>>>>> documentation for log collation:
>>>>>> 
>>>>> https://docs.trafficserver.apache.org/en/latest/admin-guide/monitoring/
>>>>> logging/log-collation.en.html
>>>>> <https://docs.trafficserver.apache.org/en/latest/admin-guide/monitoring
>>>>> /logging/log-collation.en.html>
>>>>> <https://docs.trafficserver.apache.org/en/latest/admin-guide/monitoring
>>>>> /logging/log-collation.en.html
>>>>> <https://docs.trafficserver.apache.org/en/latest/admin-guide/monitoring
>>>>> /logging/log-collation.en.html>>
>>>>>> 
>>>>>> The proposal is to remove the configurations options, statistics,
>>>>> and code for log collation.
>>>>> 
>>>>> I thought I thoughi I already replied with similar substance as Leif.
>>>>> This helped a lot when we started with ATS. It does have bugs an
>>>>> misbehaviors (eg. orphan file handling), but I don¹t think the
>>>>> maintenance burden is very high. +0
>>>>> 
>>>>> J
>> 
> 

Reply via email to