Re: Boost version upgrade

[Vinod Kone]

If it’s backwards compatible then let’s go for it. 

@vinodkone

> On Jan 9, 2018, at 9:21 AM, Benno Evers  wrote:
> 
> Hi folks,
> 
> for those of you who were looking at our build infrastructure recently, you
> may have noticed that the unfortunate combination of the default `-Werror`
> flag and the bundled boost version that contains code which generates a
> warning regarding unused local typedefs has, over the last year, spawned
> several workarounds including a hardcoded `-Wno-unused-local-typedefs`
> flag, the abuse of the `-isystem` flag to disable warnings in third-party
> dependencies and finally the `--disable-werror` option to not set `-Werror`
> by default.
> 
> To finally get rid of the warning, we were considering upgrading the
> bundled boost version to Boost 1.65 in this review chain:
> https://reviews.apache.org/r/62161/
> 
> As far as I'm aware, this change should be fully backwards-compatible for
> people who are building against a non-bundled version of boost.
> 
> Would there be any objections or concerns from the community about this?
> 
> Best regards,
> -- 
> Benno Evers
> Software Engineer, Mesosphere

Re: Boost version upgrade

[Andrew Schwartzmeyer]

I think this is a great idea. I've recently worked through fixing the 
existent warnings for Mesos on Windows, and got to the point that 
third-party dependencies are that's left generating warnings, so I'm a 
big +1 for updating the Boost bundle to fix warnings the correct way. 
I'd happily see the `-isystem` removed from the CMake build if this 
fully resolves warnings incurred by Boost.


On 01/09/2018 9:21 am, Benno Evers wrote:

Hi folks,

for those of you who were looking at our build infrastructure recently, 
you
may have noticed that the unfortunate combination of the default 
`-Werror`

flag and the bundled boost version that contains code which generates a
warning regarding unused local typedefs has, over the last year, 
spawned

several workarounds including a hardcoded `-Wno-unused-local-typedefs`
flag, the abuse of the `-isystem` flag to disable warnings in 
third-party
dependencies and finally the `--disable-werror` option to not set 
`-Werror`

by default.

To finally get rid of the warning, we were considering upgrading the
bundled boost version to Boost 1.65 in this review chain:
https://reviews.apache.org/r/62161/

As far as I'm aware, this change should be fully backwards-compatible 
for

people who are building against a non-bundled version of boost.

Would there be any objections or concerns from the community about 
this?


Best regards,

Boost version upgrade

[Benno Evers]

Hi folks,

for those of you who were looking at our build infrastructure recently, you
may have noticed that the unfortunate combination of the default `-Werror`
flag and the bundled boost version that contains code which generates a
warning regarding unused local typedefs has, over the last year, spawned
several workarounds including a hardcoded `-Wno-unused-local-typedefs`
flag, the abuse of the `-isystem` flag to disable warnings in third-party
dependencies and finally the `--disable-werror` option to not set `-Werror`
by default.

To finally get rid of the warning, we were considering upgrading the
bundled boost version to Boost 1.65 in this review chain:
https://reviews.apache.org/r/62161/

As far as I'm aware, this change should be fully backwards-compatible for
people who are building against a non-bundled version of boost.

Would there be any objections or concerns from the community about this?

Best regards,
-- 
Benno Evers
Software Engineer, Mesosphere

Re: Doc-a-thon - January 11th, 2018

[James Peach]

Just a reminder that the Docathon is this Thursday :)

> On Nov 21, 2017, at 4:14 PM, Judith Malnick  wrote:
> 
> Hi all,
> 
> I'm excited to announce the next Apache Mesos doc-a-thon!
> 
> *Date:* January 11th, 2018
> 
> Location:
> 
> Mesosphere HQ
> 
> 88 Stevenson Street
> 
> San Francisco, CA
> 
> Schedule (Pacific time):
> 
> 3 - 3:30 PM: Discuss docs projects, split into groups
> 
> 3:30 - 6:30 PM: Work on docs
> 
> 6:30 - 7 PM: Present progress
> 
> 7 - 8 PM: Drinks and hangout!
> 
> 
> If you will be attending in person, please RSVP
>  so we
> know how much food to get.
> If you plan on attending remotely, you can with this Zoom link
> .
> Feel free to brainstorm project proposals on this planning doc
> .
> 
> 
> Let me know if you have any questions. I'm looking forward to seeing all of
> you and your amazing projects!
> 
> All the Best,
> Judith
> -- 
> Judith Malnick
> Community Manager
> 310-709-1517

Re: Replacing ad hoc virtualenvs for testing and linting with tox

[Armand Grillet]

Having distributed tox.ini files and being able to run tests for multiple
environments will be helpful to develop the new Mesos CLI thus I support
this change.

Requiring developers to install tox is indeed the biggest concern with this
change; however, this process should be straightforward as it uses pip.

2018-01-09 10:03 GMT+01:00 Kevin Klues :

> I'm the one who asked Eric to send this email. I've been meaning to
> comment on it and haven't gotten around to it. I support it. We just need
> to make sure and update our CI appropriately for the new dependency (and
> make devs aware of it).
>
>
> On Tue, Jan 9, 2018 at 4:03 AM Benjamin Mahler  wrote:
>
>> +armand, benno, kevin
>>
>> On Fri, Jan 5, 2018 at 12:04 PM, Eric Chung  wrote:
>>
>>> Hello mesos devs,
>>>
>>> I'd like to propose that we replace some of our bash scripts for building
>>> ad hoc virtualenvs with tox , a
>>> tool
>>> for automating lifecycle management of virtualenvs using declarative
>>> configuration files.
>>>
>>> Specifically, virtualenvs created for the purpose of linting
>>> (support/.virtaulenv) and unit testing (in src/python) can be managed by
>>> tox, which provide the following benefits:
>>>
>>> 1. Eliminate the need for maintaining shell scripts for managing
>>> virtualenvs
>>> 2. We will no longer need to install *ALL* dependencies into the same
>>> virtualenv for the purpose of linting -- we can have distributed tox.ini
>>> files in wherever python linting is required, and just run tox there.
>>> 3. Easily run tests for multiple environments, e.g. python3 vs python2.
>>> This will make migration to python3 much easier, which we are facing
>>> increasing pressure to address.
>>>
>>> The biggest concern here would probably the change in dependencies, since
>>> it may seem like we're adding an additional dependency to mesos. However
>>> since virtualenv is a dependency of tox, we will not break any existing
>>> dependencies, as requiring tox will automatically require virtualenv.
>>> Otherwise I don't really see any downside in making the switch.
>>>
>>> Please let me know what you think!
>>>
>>> Eric
>>>
>>
>>


-- 
Armand Grillet
Software Engineer, Mesosphere