+1
> On May 10, 2019, at 8:20 PM, Leif Hedstrom wrote:
>
> +1
>
>> On May 10, 2019, at 17:45, Bryan Call wrote:
>>
>> I would like to propose that we move from the IRC to Slack for IM
>> communication by June 1st. This is in response to ASF moving to Slack for
>> Infra and other channels
+1
> On May 10, 2019, at 17:45, Bryan Call wrote:
>
> I would like to propose that we move from the IRC to Slack for IM
> communication by June 1st. This is in response to ASF moving to Slack for
> Infra and other channels and spamming that has happened on the IRC over the
> last year.
>
>
+1
> On May 10, 2019, at 1:08 PM, Leif Hedstrom wrote:
>
> This configuration option only has meaning on Solaris, a platform that we
> currently don’t support. As such, it’s actually confusing that it’s there to
> begin with, since it doesn’t do anything on any of the platforms we do
> suppor
+1
> On May 10, 2019, at 4:45 PM, Bryan Call wrote:
>
> I would like to propose that we move from the IRC to Slack for IM
> communication by June 1st. This is in response to ASF moving to Slack for
> Infra and other channels and spamming that has happened on the IRC over the
> last year.
>
+1
On Fri, May 10, 2019 at 4:54 PM Walt Karas wrote:
>
> +1
>
> On Fri, May 10, 2019 at 6:45 PM Bryan Call wrote:
>>
>> I would like to propose that we move from the IRC to Slack for IM
>> communication by June 1st. This is in response to ASF moving to Slack for
>> Infra and other channels an
+1
On Fri, May 10, 2019 at 6:45 PM Bryan Call wrote:
> I would like to propose that we move from the IRC to Slack for IM
> communication by June 1st. This is in response to ASF moving to Slack for
> Infra and other channels and spamming that has happened on the IRC over the
> last year.
>
> Thi
I would like to propose that we move from the IRC to Slack for IM communication
by June 1st. This is in response to ASF moving to Slack for Infra and other
channels and spamming that has happened on the IRC over the last year.
This would require that people without an apache.org email address t
+1 - I approved the PR
-Bryan
> On May 10, 2019, at 1:08 PM, Leif Hedstrom wrote:
>
> This configuration option only has meaning on Solaris, a platform that we
> currently don’t support. As such, it’s actually confusing that it’s there to
> begin with, since it doesn’t do anything on any of
This configuration option only has meaning on Solaris, a platform that we
currently don’t support. As such, it’s actually confusing that it’s there to
begin with, since it doesn’t do anything on any of the platforms we do support.
I’d like to remove this option, and the code around it.
Thanks,
I would also like to add that people should also send an email to the dev@
mailing list with [PROPOSAL] in the subject with a link over to the issue. I
don’t know if people look at new issues coming in.
-Bryan
> On May 10, 2019, at 11:33 AM, Bryan Call wrote:
>
> +1 - I definite agree with
+1 - I definite agree with this as was about to push send on a email about this
before Leif informed he already did. :)
-Bryan
> On May 9, 2019, at 9:06 AM, Leif Hedstrom wrote:
>
> Hi,
>
> As fa Follow-up to previous emails, I’d like to propose that new features,
> and major code changes
+1
On Fri, May 10, 2019 at 11:13 AM Mark Moseley wrote:
>
> As someone who deliberately breaks ATS's ability to modify configs, +1 :)
>
> On Fri, May 10, 2019 at 9:54 AM Leif Hedstrom wrote:
>>
>>
>>
>> On May 10, 2019, at 10:10 AM, Sudheer Vinukonda
>> wrote:
>>
>> Just to confirm, when you s
As someone who deliberately breaks ATS's ability to modify configs, +1 :)
On Fri, May 10, 2019 at 9:54 AM Leif Hedstrom wrote:
>
>
> On May 10, 2019, at 10:10 AM, Sudheer Vinukonda <
> sudheervinuko...@yahoo.com> wrote:
>
> Just to confirm, when you say "..make this behavior the only supported
>
> On May 10, 2019, at 10:10 AM, Sudheer Vinukonda
> wrote:
>
> Just to confirm, when you say "..make this behavior the only supported
> behavior in v9.0.0..", are you implying to not persist dynamic config changes
> into records.config?
>
> Assuming the answer is yes, I'm +1 on the proposa
Hi all,
Just a heads up, but our 3x VMs are running FBSD 11.2, which is soon to be
EOLifed. Rather than upgrading to 11.3, and then later 12.0, I much prefer that
we go straight to v12.0. In an ideal world, we’d be able to run multiple
FreeBSD versions, but alas, we do not have the resources fo
Just to confirm, when you say "..make this behavior the only supported
behavior in v9.0.0..", are you implying to not persist dynamic config changes
into records.config?
Assuming the answer is yes, I'm +1 on the proposal to make that as the de-facto
and only behavior.
Thanks,
Sudheer
On Fr
Hi all,
I’d like to propose that we remove the configuration option
proxy.config.disable_configuration_modification, and make this behavior the
only supported behavior in v9.0.0. I know of at least one user who would
appreciate this …
Doing so, would also let us eliminate all the Rollback.cc <
+1
On Fri, May 10, 2019 at 6:53 AM Steven R. Feltner
wrote:
> +1 - I like this idea a lot
>
>
> On 5/9/19, 12:06 PM, "Leif Hedstrom" wrote:
>
> Notice: This email is from an external sender.
>
>
>
> Hi,
>
> As fa Follow-up to previous emails, I’d like to propose that new
> features
+1 - I like this idea a lot
On 5/9/19, 12:06 PM, "Leif Hedstrom" wrote:
Notice: This email is from an external sender.
Hi,
As fa Follow-up to previous emails, I’d like to propose that new features,
and major code changes affecting large portions of code and beh
+1
On 5/9/19, 6:24 PM, "Leif Hedstrom" wrote:
Notice: This email is from an external sender.
Hi all,
I’d like to propose that we eliminate the “email” feature out of Alarms. I
think this is misguided, and in reality, could be wrapped into a script if
someone re
20 matches
Mail list logo
