Given MESOS-5806 <https://issues.apache.org/jira/browse/MESOS-5806> and the
fixes landed by Jie and Qian, I would give a
-1 (non-binding)

I think MESOS-5806 is critical for running containers (with images) on the
host network, which seems like an important use-case to cover. Hence, would
definitely want this fixed in 1.0 .

On Sat, Jul 16, 2016 at 12:41 AM, Jörg Schad <[email protected]> wrote:

> +1 non-binding
>
> {OSX, Ubuntu 16)
> - sudo make check
> - upgrade script
>
> Short question: until when is this vote open?
>
>
> On Sat, Jul 16, 2016 at 7:40 AM, tommy xiao <[email protected]> wrote:
> >
> >> +1
> >>
> >> Tested on Fedora release 23 (Twenty Three)
> >>
> >> - make check
> >> - 1.0.0-rc2
> >>
> >> 2016-07-15 23:01 GMT+08:00 haosdent <[email protected]>:
> >>
> >>> +1
> >>>
> >>> Tested on CentOS 7.
> >>>
> >>> - sudo make check
> >>> - upgrade from 0.28.2 to 1.0.0-rc2
> >>>
> >>> On Fri, Jul 15, 2016 at 7:47 PM, Alex Rukletsov <[email protected]>
> >>> wrote:
> >>>
> >>>> Haosdent investigated the issue, and it seems that health checks do
> >>>> work for docker executor. Hence I retract my negative vote.
> >>>>
> >>>> On Fri, Jul 15, 2016 at 12:57 PM, Alex Rukletsov <[email protected]
> >
> >>>> wrote:
> >>>>
> >>>>> -1 (binding): MESOS-5848
> >>>>> <https://issues.apache.org/jira/browse/MESOS-5848>. The fix is on
> the
> >>>>> way.
> >>>>>
> >>>>> On Wed, Jul 13, 2016 at 1:19 AM, Zhitao Li <[email protected]>
> >>>>> wrote:
> >>>>>
> >>>>>> +1 (nonbinding)
> >>>>>>
> >>>>>> Tested by 1)running all tests on Mac OS, 2) perform upgrade and
> >>>>>> downgrade on a small test cluster for both master and slave.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Jul 11, 2016 at 10:13 AM, Kapil Arya <[email protected]>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> None of the stable builds have SSL yet. The first SSL-enabled
> stable
> >>>>>>> build
> >>>>>>> will be 1.0.0. Sorry for the confusion.
> >>>>>>>
> >>>>>>> Kapil
> >>>>>>>
> >>>>>>> On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <[email protected]>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> > Hi Kapil,
> >>>>>>> >
> >>>>>>> > Do you mean that the stable builds from
> >>>>>>> > http://open.mesosphere.com/downloads/mesos is using the new
> >>>>>>> configuration?
> >>>>>>> >
> >>>>>>> > On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <
> [email protected]>
> >>>>>>> wrote:
> >>>>>>> >
> >>>>>>> >> The binary rpm/deb packages can be found here:
> >>>>>>> >>
> >>>>>>>
> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
> >>>>>>> >> .
> >>>>>>> >>
> >>>>>>> >> Please note that starting with the 1.0.0 release (including RCs
> >>>>>>> and
> >>>>>>> >> recent nightly builds), Mesos is configured with SSL and
> 3rdparty
> >>>>>>> >> module dependency installation. Here is the configure command
> >>>>>>> line:
> >>>>>>> >>     ./configure --enable-libevent --enable-ssl
> >>>>>>> >> --enable-install-module-dependencies
> >>>>>>> >>
> >>>>>>> >> As always, the stable builds are available at:
> >>>>>>> >>     http://open.mesosphere.com/downloads/mesos
> >>>>>>> >>
> >>>>>>> >> The instructions for nightly builds are available at:
> >>>>>>> >>     http://open.mesosphere.com/downloads/mesos-nightly/
> >>>>>>> >>
> >>>>>>> >> Best,
> >>>>>>> >> Kapil
> >>>>>>> >>
> >>>>>>> >>
> >>>>>>> >> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <
> [email protected]>
> >>>>>>> wrote:
> >>>>>>> >> >
> >>>>>>> >> > Hi all,
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > Please vote on releasing the following candidate as Apache
> >>>>>>> Mesos 1.0.0.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > 1.0.0 includes the following:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >>
> >>>>>>>
> --------------------------------------------------------------------------------
> >>>>>>> >> >
> >>>>>>> >> >   * Scheduler and Executor v1 HTTP APIs are now considered
> >>>>>>> stable.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4791] - **Experimental** support for v1 Master and
> >>>>>>> Agent
> >>>>>>> >> APIs.
> >>>>>>> >> > These
> >>>>>>> >> >
> >>>>>>> >> >     APIs let operators and services (monitoring, load
> >>>>>>> balancers) send
> >>>>>>> >> HTTP
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     requests to '/api/v1' endpoint on master or agent. See
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     `docs/operator-http-api.md` for details.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4828] - **Experimental** support for a new
> `disk/xfs'
> >>>>>>> >> isolator
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     has been added to isolate disk resources more efficiently.
> >>>>>>> Please
> >>>>>>> >> refer
> >>>>>>> >> > to
> >>>>>>> >> >
> >>>>>>> >> >     docs/mesos-containerizer.md for more details.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4355] - **Experimental** support for Docker volume
> >>>>>>> plugin. We
> >>>>>>> >> > added a
> >>>>>>> >> >
> >>>>>>> >> >     new isolator 'docker/volume' which allows users to use
> >>>>>>> external
> >>>>>>> >> volumes
> >>>>>>> >> > in
> >>>>>>> >> >
> >>>>>>> >> >     Mesos containerizer. Currently, the isolator interacts
> with
> >>>>>>> the
> >>>>>>> >> Docker
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     volume plugins using a tool called 'dvdcli'. By speaking
> >>>>>>> the Docker
> >>>>>>> >> > volume
> >>>>>>> >> >
> >>>>>>> >> >     plugin API, most of the Docker volume plugins are
> supported.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4641] - **Experimental** A new network isolator,
> the
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     `network/cni` isolator, has been introduced in the
> >>>>>>> >> > `MesosContainerizer`. The
> >>>>>>> >> >
> >>>>>>> >> >     `network/cni` isolator implements the Container Network
> >>>>>>> Interface
> >>>>>>> >> (CNI)
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     specification proposed by CoreOS.  With CNI the
> >>>>>>> `network/cni`
> >>>>>>> >> isolator
> >>>>>>> >> > is
> >>>>>>> >> >
> >>>>>>> >> >     able to allocate a network namespace to Mesos containers
> >>>>>>> and attach
> >>>>>>> >> the
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     container to different types of IP networks by invoking
> >>>>>>> network
> >>>>>>> >> drivers
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     called CNI plugins.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has
> been
> >>>>>>> >> refactored
> >>>>>>> >> > in
> >>>>>>> >> >
> >>>>>>> >> >     order to decouple the ACLs definition language from the
> >>>>>>> interface.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     It additionally includes the option of retrieving
> >>>>>>> `ObjectApprover`.
> >>>>>>> >> An
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     `ObjectApprover` can be used to synchronously check
> >>>>>>> authorizations
> >>>>>>> >> for
> >>>>>>> >> > a
> >>>>>>> >> >
> >>>>>>> >> >     given object and is hence useful when authorizing a large
> >>>>>>> number of
> >>>>>>> >> > objects
> >>>>>>> >> >
> >>>>>>> >> >     and/or large objects (which need to be copied using
> request
> >>>>>>> based
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     authorization). NOTE: This is a **breaking change** for
> >>>>>>> authorizer
> >>>>>>> >> > modules.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-5405] - The `subject` and `object` fields in
> >>>>>>> >> > authorization::Request
> >>>>>>> >> >
> >>>>>>> >> >     have been changed from required to optional. If either of
> >>>>>>> these
> >>>>>>> >> fields
> >>>>>>> >> > is
> >>>>>>> >> >
> >>>>>>> >> >     not set, the request should only be authorized if any
> >>>>>>> subject/object
> >>>>>>> >> > should
> >>>>>>> >> >
> >>>>>>> >> >     be allowed.
> >>>>>>> >> >
> >>>>>>> >> >     NOTE: This is a semantic change for authorizer modules.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based
> >>>>>>> HTTP
> >>>>>>> >> > endpoint
> >>>>>>> >> >
> >>>>>>> >> >     filtering enables operators to restrict what part of the
> >>>>>>> cluster
> >>>>>>> >> state
> >>>>>>> >> > a
> >>>>>>> >> >
> >>>>>>> >> >     user is authorized to see.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     Consider for example the `/state` master endpoint: an
> >>>>>>> operator can
> >>>>>>> >> now
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     authorize users to only see a subset of the running
> >>>>>>> frameworks,
> >>>>>>> >> tasks,
> >>>>>>> >> > or
> >>>>>>> >> >
> >>>>>>> >> >     executors. The following endpoints support HTTP endpoint
> >>>>>>> filtering:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     '/state', '/state-summary', '/tasks',
> >>>>>>> '/frameworks','/weights',
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     and '/roles'. Additonally the following v1 API calls
> support
> >>>>>>> >> filtering:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE',
> and
> >>>>>>> >> > 'GET_TASKS'.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4909] - Tasks can now specify a kill policy. They
> are
> >>>>>>> >> > best-effort,
> >>>>>>> >> >
> >>>>>>> >> >     because machine failures or forcible terminations may
> occur.
> >>>>>>> >> Currently,
> >>>>>>> >> > the
> >>>>>>> >> >
> >>>>>>> >> >     only available kill policy is how long to wait between
> >>>>>>> graceful and
> >>>>>>> >> > forcible
> >>>>>>> >> >
> >>>>>>> >> >     task kill. In the future, more policies may be available
> >>>>>>> (e.g.
> >>>>>>> >> hitting
> >>>>>>> >> > an
> >>>>>>> >> >
> >>>>>>> >> >     HTTP endpoint, running a command, etc). Note that it is
> the
> >>>>>>> >> executor's
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     responsibility to enforce kill policies. For executor-less
> >>>>>>> >> > command-based
> >>>>>>> >> >
> >>>>>>> >> >     tasks, the kill is performed via sending a signal to the
> >>>>>>> task
> >>>>>>> >> process:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     SIGTERM for the graceful kill and SIGKILL for the forcible
> >>>>>>> kill. For
> >>>>>>> >> > docker
> >>>>>>> >> >
> >>>>>>> >> >     executor-less tasks the grace period is passed to 'docker
> >>>>>>> stop
> >>>>>>> >> --time'.
> >>>>>>> >> > This
> >>>>>>> >> >
> >>>>>>> >> >     feature supersedes the '--docker_stop_timeout', which is
> now
> >>>>>>> >> > deprecated.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4908] - The task kill policy defined within
> >>>>>>> 'TaskInfo' can
> >>>>>>> >> now
> >>>>>>> >> > be
> >>>>>>> >> >
> >>>>>>> >> >     overridden when the scheduler kills the task. This can be
> >>>>>>> used by
> >>>>>>> >> > schedulers
> >>>>>>> >> >
> >>>>>>> >> >     to forcefully kill a task which is already being killed,
> >>>>>>> e.g. if
> >>>>>>> >> > something
> >>>>>>> >> >
> >>>>>>> >> >     went wrong during a graceful kill and a forcible kill is
> >>>>>>> desired.
> >>>>>>> >> Note
> >>>>>>> >> > that
> >>>>>>> >> >
> >>>>>>> >> >     it is the executor's responsibility to honor the
> >>>>>>> >> > 'Event.kill.kill_policy'
> >>>>>>> >> >
> >>>>>>> >> >     field and override the task's kill policy and kill policy
> >>>>>>> from a
> >>>>>>> >> > previous
> >>>>>>> >> >
> >>>>>>> >> >     kill task request. To use this feature, schedulers and
> >>>>>>> executors
> >>>>>>> >> must
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     support HTTP API; use the '--http_command_executor' agent
> >>>>>>> flag to
> >>>>>>> >> > ensure
> >>>>>>> >> >
> >>>>>>> >> >     the agent launches the HTTP API based command executor.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4949] - The executor shutdown grace period can now
> be
> >>>>>>> >> configured
> >>>>>>> >> > in
> >>>>>>> >> >
> >>>>>>> >> >     `ExecutorInfo`, which overrides the agent flag. When
> >>>>>>> shutting down
> >>>>>>> >> an
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     executor the agent will wait in a best-effort manner for
> >>>>>>> the grace
> >>>>>>> >> > period
> >>>>>>> >> >
> >>>>>>> >> >     specified here before forcibly destroying the container.
> The
> >>>>>>> >> executor
> >>>>>>> >> > must
> >>>>>>> >> >
> >>>>>>> >> >     not assume that it will always be allotted the full grace
> >>>>>>> period, as
> >>>>>>> >> > the
> >>>>>>> >> >
> >>>>>>> >> >     agent may decide to allot a shorter period and failures /
> >>>>>>> forcible
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     terminations may occur. Together with kill policies this
> >>>>>>> gives
> >>>>>>> >> > frameworks
> >>>>>>> >> >
> >>>>>>> >> >     flexibility around how to clean up tasks and executors.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-3094] - **Experimental** support for launching
> mesos
> >>>>>>> tasks on
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     Windows. Note that there are no isolation guarantees
> >>>>>>> provided yet.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4090] - The `mesos.native` python module has been
> >>>>>>> split into
> >>>>>>> >> > two,
> >>>>>>> >> >
> >>>>>>> >> >     `mesos.executor` and `mesos.scheduler`. This change also
> >>>>>>> removes
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     un-necessary 3rd party dependencies from `mesos.executor`
> >>>>>>> and
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     `mesos.scheduler`. `mesos.native` still exists, combining
> >>>>>>> both
> >>>>>>> >> modules
> >>>>>>> >> > for
> >>>>>>> >> >
> >>>>>>> >> >     backwards compatibility with existing code.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is
> >>>>>>> complete. To
> >>>>>>> >> > support
> >>>>>>> >> >
> >>>>>>> >> >     the rename, new duplicate flags (e.g.,
> >>>>>>> --agent_reregister_timeout),
> >>>>>>> >> new
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     binaries (e.g., mesos-agent) and WebUI sandbox links have
> >>>>>>> been
> >>>>>>> >> added.
> >>>>>>> >> > All
> >>>>>>> >> >
> >>>>>>> >> >     the logging output has been updated to use the term
> 'agent'
> >>>>>>> now.
> >>>>>>> >> Flags,
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     binaries and scripts with 'slave' keyword have been
> >>>>>>> deprecated (see
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     "Deprecations section below").
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4312] - **Experimental** support for building and
> >>>>>>> running
> >>>>>>> >> mesos
> >>>>>>> >> > on
> >>>>>>> >> >
> >>>>>>> >> >     IBM PowerPC platform.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4189] - Weights for resource roles can now be
> >>>>>>> configured
> >>>>>>> >> > dynamically
> >>>>>>> >> >
> >>>>>>> >> >     via the new '/weights' endpoint on the master.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource
> >>>>>>> in the
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     Mesos "unified" containerizer. This support includes
> running
> >>>>>>> >> containers
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     with and without filesystem isolation (i.e. running both
> >>>>>>> imageless
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     containers as well as containers using a docker image).
> >>>>>>> Frameworks
> >>>>>>> >> must
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     opt-in to receiving GPU resources via the GPU_RESOURCES
> >>>>>>> framework
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     capability (see the scarce resource problem in
> MESOS-5377).
> >>>>>>> We
> >>>>>>> >> support
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     'nvidia-docker'-style docker containers by injecting a
> >>>>>>> volume that
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     contains the Nvidia libraries / binaries when the docker
> >>>>>>> image has
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     the 'com.nvidia.volumes.needed' label. Support for the
> >>>>>>> docker
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     containerizer will come in a future release.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-5724] - SSL certificate validation allows for
> >>>>>>> additional IP
> >>>>>>> >> > address
> >>>>>>> >> >
> >>>>>>> >> >     subject alternative name extension verification.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > The CHANGELOG for the release is available at:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >>
> >>>>>>>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >>
> >>>>>>>
> --------------------------------------------------------------------------------
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > The candidate for Mesos 1.0.0 release is available at:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >>
> >>>>>>>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > The tag to be voted on is 1.0.0-rc2:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >>
> >>>>>>>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > The MD5 checksum of the tarball can be found at:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >>
> >>>>>>>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > The signature of the tarball can be found at:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >>
> >>>>>>>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > The PGP key used to sign the release is here:
> >>>>>>> >> >
> >>>>>>> >> > https://dist.apache.org/repos/dist/release/mesos/KEYS
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > The JAR is up in Maven in a staging repository here:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>>
> https://repository.apache.org/content/repositories/orgapachemesos-1149
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > Please vote on releasing this package as Apache Mesos 1.0.0!
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes
> >>>>>>> if a
> >>>>>>> >> > majority of at least 3 +1 PMC votes are cast.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > [ ] +1 Release this package as Apache Mesos 1.0.0
> >>>>>>> >> >
> >>>>>>> >> > [ ] -1 Do not release this package because ...
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > Thanks,
> >>>>>>> >> >
> >>>>>>> >> > Vinod
> >>>>>>> >>
> >>>>>>> >
> >>>>>>> >
> >>>>>>> >
> >>>>>>> > --
> >>>>>>> > Cheers,
> >>>>>>> >
> >>>>>>> > Zhitao Li
> >>>>>>> >
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Cheers,
> >>>>>>
> >>>>>> Zhitao Li
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Best Regards,
> >>> Haosdent Huang
> >>>
> >>
> >>
> >>
> >> --
> >> Deshi Xiao
> >> Twitter: xds2000
> >> E-mail: xiaods(AT)gmail.com
> >>
> >
> >
>



-- 
Avinash Sridharan, Mesosphere
+1 (323) 702 5245

Reply via email to