Re: mesos git commit: Updated the outdated network isolator configure flag.

This commit enables the port mapping isolator by default. Was that intended? Among other things, it breaks the build on OSX: $ ../mesos/configure --disable-java --disable-python [...] configure: error: cannot build network isolator

Re: Use of ACLs.RegisterAgent.agent

FYI, I merged the change to rename this field into the master and 1.3.x branches; it will be included in the next 1.3.0 release candidate. Neil On Mon, May 22, 2017 at 10:43 AM, Alexander Rojas wrote: > Hey guys, > > We just noted that there was an error when the

Re: Welcome Gilbert Song as a new committer and PMC member!

Congratulations Gilbert! Well-deserved! Neil On Wed, May 24, 2017 at 10:32 AM, Jie Yu wrote: > Hi folks, > > I' happy to announce that the PMC has voted Gilbert Song as a new committer > and member of PMC for the Apache Mesos project. Please join me to > congratulate him! >

Re: [VOTE] Release Apache Mesos 1.3.0 (rc2)

The vote has failed; we'll cut a new release shortly. The release blocker (MESOS-7521) has been investigated and fixed. The next RC will also include MESOS-7538, as well as the `register_agents` ACL change mentioned in a different thread. Neil On Wed, May 17, 2017 at 3:11 PM, Yan Xu

Re: Moving Mesos builds reqs from GCC 4.8.1+ to GCC 4.9.0+

On Tue, May 30, 2017 at 12:58 PM, Michael Park wrote: > I'm all for moving to GCC 4.9+. > > I'd love to get C++14 and bump to GCC 5, but I think we should do an > investigation for "reasonable availability" before we do that. I agree, although I'd think a similar investigation

Re: [VOTE] Release Apache Mesos 1.3.0 (rc3)

On Tue, May 30, 2017 at 2:36 PM, Vinod Kone wrote: > Ran on ASF CI. > > Found following issues. > > Failed test: CommandExecutorCheckTest.CommandCheckDeliveredAndReconciled >

Re: [VOTE] Release Apache Mesos 1.3.0 (rc3)

On Tue, May 30, 2017 at 2:36 PM, Vinod Kone wrote: > Failed test: OneWayPartitionTest.MasterToSlave >

Re: RFC: Partition Awareness

Hi Ben, The argument for changing the semantics is that correct frameworks should _always_ have accounted for the possibility that TASK_LOST tasks would go back to running (due to the non-strict registry semantics). The proposed change would just increase the probability of this behavior

Re: June 3rd: MesosCon North America CFP due!

Hi Jay, The CFP deadline has been extended to June 30. Neil On Sat, Jun 3, 2017 at 12:55 AM Jay Guo wrote: > According to the link CFP for MesosCon North America > > ​ the CFP closes by

Re: [VOTE] Release Apache Mesos 1.3.0 (rc3)

On Tue, May 30, 2017 at 3:43 PM, Neil Conway <neil.con...@gmail.com> wrote: > Attached is the test log for this failure. From a quick look, seems as > though the agent starts to launch the task, including forking the > child process, but no subsequent task status updates or

Version numbers during development

Our current practice is that when we create a branch for version X, we bump the version number in the "master" branch to X+1. For example, we just created the 1.3.x branch, and bumped the version number in master to "1.4.0". Proposal: we should instead use a version number like "1.4.0-devel" in

Re: [4/6] mesos git commit: Checked validity of master and agent version numbers on startup.

t-wip-us.apache.org/repos/asf/mesos/repo >> Commit: http://git-wip-us.apache.org/repos/asf/mesos/commit/5a5dd8a4 >> Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/5a5dd8a4 >> Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/5a5dd8a4 >> >> Branch: refs/hea

Re: documenting test expactations

My two cents: (1) I almost always need to read the test to understand/debug a test failure. (2) As long as the intent of the test is clear, I'm not picky about whether clarifying comments take the form of C++ comments or explanatory EXPECT messages. One thing I would be opposed to is adding

Re: [VOTE] Release Apache Mesos 1.3.0 (rc1)

Personally, I'm not convinced that we need to fix MESOS-7378. The problem is essentially a bug in glibc that was fixed 6 years ago. (As a point of reference, the oldest version of g++ we support was released 2 years ago... :) ) Neil On Mon, May 8, 2017 at 3:45 PM, Yan Xu wrote: > I

Re: Version numbers during development

) updating the release process documentation accordingly. If you have any concerns, please let me know. Neil On Fri, May 5, 2017 at 4:29 PM, Neil Conway <neil.con...@gmail.com> wrote: > In my experience, this is reasonably common. For example, Postgres > uses version number

Re: Version numbers during development

gt; > On Fri, May 5, 2017 at 1:27 PM, Zhitao Li <zhitaoli...@gmail.com> wrote: > >> +1 >> >> Sent from my iPhone >> >> > On May 5, 2017, at 12:56 PM, Neil Conway <neil.con...@gmail.com> wrote: >> > >> > Our current practice is that

Re: Moving Mesos builds reqs from GCC 4.8.1+ to GCC 4.9.0+

It seems that if we moved to GCC 5, we'd also be able to move to C++14 (https://gcc.gnu.org/projects/cxx-status.html#cxx14). CentOS 6 users will need to install devtoolset anyway (which makes it easy to get GCC 5 or 6), so I wonder if skipping directly to requiring GCC 5 would be feasible? Neil

<    1   2