Re: 1.0 Release Candidate

[Vinod Kone]

Transitioning issues tagged with 0.29.0 to 1.0.0. now...Please don't use
0.29.0 fix/affects version anymore.

On Sun, May 29, 2016 at 8:24 AM, tommy xiao <xia...@gmail.com> wrote:

> cool.
>
> 2016-05-29 19:03 GMT+08:00 haosdent <haosd...@gmail.com>:
>
>> +1s
>>
>> On Sun, May 29, 2016 at 7:01 PM, Klaus Ma <klaus1982...@gmail.com> wrote:
>>
>>> v1.0, exciting :).
>>>
>>> 
>>> Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
>>> Platform OpenSource Technology, STG, IBM GCG
>>> +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
>>>
>>>
>>> > Date: Sun, 29 May 2016 02:31:47 -0700
>>> > Subject: Re: 1.0 Release Candidate
>>> > From: a...@mesosphere.io
>>> > To: u...@mesos.apache.org
>>> > CC: vinodk...@apache.org; dev@mesos.apache.org
>>>
>>> >
>>> > FYI, I made an alternate 1.0 release dashboard with a longer timeframe
>>> for
>>> > the created vs. resolved chart, and added a couple of my favorite
>>> widgets.
>>> > Feel free to use anything you find helpful.
>>> >
>>> >
>>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12328256
>>> >
>>> > On Thu, May 26, 2016 at 9:44 PM, Vinod Kone <vinodk...@apache.org>
>>> wrote:
>>> >
>>> > > This is the release dashboard:
>>> > >
>>> > >
>>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12328255
>>> > >
>>> > > *NOTE: *If you have set a Fix Version of 0.29.0 on a ticket that is
>>> not a
>>> > > blocker for 0.29.0/1.0 release, please unset the fix version.
>>> > >
>>> > > On Thu, May 26, 2016 at 3:44 PM, Vinod Kone <vinodk...@apache.org>
>>> wrote:
>>> > >
>>> > >> Thanks for asking the questions Zameer. Wanted to give some
>>> clarification
>>> > >> regarding the thought process for releasing 1.0.
>>> > >>
>>> > >> The reason for cutting a 1.0, is because we want to signal that the
>>> > >> Mesos project has reached a level of maturity to the wider
>>> community. Among
>>> > >> other things we are confident at this point that the *foundations*
>>> we laid
>>> > >> for the new APIs are mature and could be evolved in a backwards
>>> compatible
>>> > >> way. We laid the foundations almost an year ago (at last MesosCon)
>>> and
>>> > >> since then have been busy implementing the backend to drive the
>>> API. Even
>>> > >> the newly released design doc for the operator API is built on the
>>> same
>>> > >> foundations as the scheduler/executor APIs. While we have been
>>> tweaking the
>>> > >> API backend for a while now the API definitions have mostly stayed
>>> the
>>> > >> same. Part of the reason it took this long is because we really
>>> wanted to
>>> > >> be sure the basic building blocks were solid.
>>> > >>
>>> > >> MesosCon is a great opportunity for us to drum up excitement about
>>> the
>>> > >> new APIs and invite them to start using/testing it. Like any other
>>> OSS
>>> > >> project, as people and organizations start using the new APIs in
>>> staging
>>> > >> and production, we will make stability and implementation
>>> improvements. The
>>> > >> long period for the RC will also help catching issues with API
>>> foundations
>>> > >> themselves. We have had a bit of chicken and egg problem having
>>> people
>>> > >> consume the new APIs because most don't want to use it in
>>> production unless
>>> > >> it is declared production ready and we can't call it production
>>> ready until
>>> > >> someone uses them in production.
>>> > >>
>>> > >> Having said all that stability and production readiness is
>>> paramount for
>>> > >> the project. That is never going to change. In the case of the new
>>> APIs,
>>> > >> we have developed C++ frameworks using the new APIs and having been
>>> running
>>> > >> them as part of ASF CI for months now. Mesosphere, for example,
>>> also has an
>>>

Re: 1.0 Release Candidate

[tommy xiao]

cool.

2016-05-29 19:03 GMT+08:00 haosdent <haosd...@gmail.com>:

> +1s
>
> On Sun, May 29, 2016 at 7:01 PM, Klaus Ma <klaus1982...@gmail.com> wrote:
>
>> v1.0, exciting :).
>>
>> 
>> Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
>> Platform OpenSource Technology, STG, IBM GCG
>> +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
>>
>>
>> > Date: Sun, 29 May 2016 02:31:47 -0700
>> > Subject: Re: 1.0 Release Candidate
>> > From: a...@mesosphere.io
>> > To: u...@mesos.apache.org
>> > CC: vinodk...@apache.org; dev@mesos.apache.org
>>
>> >
>> > FYI, I made an alternate 1.0 release dashboard with a longer timeframe
>> for
>> > the created vs. resolved chart, and added a couple of my favorite
>> widgets.
>> > Feel free to use anything you find helpful.
>> >
>> >
>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12328256
>> >
>> > On Thu, May 26, 2016 at 9:44 PM, Vinod Kone <vinodk...@apache.org>
>> wrote:
>> >
>> > > This is the release dashboard:
>> > >
>> > >
>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12328255
>> > >
>> > > *NOTE: *If you have set a Fix Version of 0.29.0 on a ticket that is
>> not a
>> > > blocker for 0.29.0/1.0 release, please unset the fix version.
>> > >
>> > > On Thu, May 26, 2016 at 3:44 PM, Vinod Kone <vinodk...@apache.org>
>> wrote:
>> > >
>> > >> Thanks for asking the questions Zameer. Wanted to give some
>> clarification
>> > >> regarding the thought process for releasing 1.0.
>> > >>
>> > >> The reason for cutting a 1.0, is because we want to signal that the
>> > >> Mesos project has reached a level of maturity to the wider
>> community. Among
>> > >> other things we are confident at this point that the *foundations*
>> we laid
>> > >> for the new APIs are mature and could be evolved in a backwards
>> compatible
>> > >> way. We laid the foundations almost an year ago (at last MesosCon)
>> and
>> > >> since then have been busy implementing the backend to drive the API.
>> Even
>> > >> the newly released design doc for the operator API is built on the
>> same
>> > >> foundations as the scheduler/executor APIs. While we have been
>> tweaking the
>> > >> API backend for a while now the API definitions have mostly stayed
>> the
>> > >> same. Part of the reason it took this long is because we really
>> wanted to
>> > >> be sure the basic building blocks were solid.
>> > >>
>> > >> MesosCon is a great opportunity for us to drum up excitement about
>> the
>> > >> new APIs and invite them to start using/testing it. Like any other
>> OSS
>> > >> project, as people and organizations start using the new APIs in
>> staging
>> > >> and production, we will make stability and implementation
>> improvements. The
>> > >> long period for the RC will also help catching issues with API
>> foundations
>> > >> themselves. We have had a bit of chicken and egg problem having
>> people
>> > >> consume the new APIs because most don't want to use it in production
>> unless
>> > >> it is declared production ready and we can't call it production
>> ready until
>> > >> someone uses them in production.
>> > >>
>> > >> Having said all that stability and production readiness is paramount
>> for
>> > >> the project. That is never going to change. In the case of the new
>> APIs,
>> > >> we have developed C++ frameworks using the new APIs and having been
>> running
>> > >> them as part of ASF CI for months now. Mesosphere, for example, also
>> has an
>> > >> internal cluster where frameworks using these new APIs have been
>> baking for
>> > >> a while and had done (and doing) rigorous tests (network partitions,
>> > >> scaling tests, functional tests). Community members from IBM have
>> also been
>> > >> instrumental in testing the new APIs. We are hoping after 1.0 more
>> people
>> > >> would be willing and excited to consume these new APIs and stress
>> test in
>> > >> their environments.
>> > >>
>&g

Re: 1.0 Release Candidate

[Adam Bordelon]

FYI, I made an alternate 1.0 release dashboard with a longer timeframe for
the created vs. resolved chart, and added a couple of my favorite widgets.
Feel free to use anything you find helpful.

https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12328256

On Thu, May 26, 2016 at 9:44 PM, Vinod Kone  wrote:

> This is the release dashboard:
>
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12328255
>
> *NOTE: *If you have set a Fix Version of 0.29.0 on a ticket that is not a
> blocker for 0.29.0/1.0 release, please unset the fix version.
>
> On Thu, May 26, 2016 at 3:44 PM, Vinod Kone  wrote:
>
>> Thanks for asking the questions Zameer. Wanted to give some clarification
>> regarding the thought process for releasing 1.0.
>>
>> The reason for cutting  a 1.0, is because we want to signal that the
>> Mesos project has reached a level of maturity to the wider community. Among
>> other things we are confident at this point that the *foundations* we laid
>> for the new APIs are mature and could be evolved in a backwards compatible
>> way. We laid the foundations almost an year ago (at last MesosCon) and
>> since then have been busy implementing the backend to drive the API.  Even
>> the newly released design doc for the operator API is built on the same
>> foundations as the scheduler/executor APIs. While we have been tweaking the
>> API backend for a while now the API definitions have mostly stayed the
>> same. Part of the reason it took this long is because we really wanted to
>> be sure the basic building blocks were solid.
>>
>> MesosCon is a great opportunity for us to drum up excitement about the
>> new APIs and invite them to start using/testing it. Like any other OSS
>> project, as people and organizations start using the new APIs in staging
>> and production, we will make stability and implementation improvements. The
>> long period for the RC will also help catching issues with API foundations
>> themselves. We have had a bit of chicken and egg problem having people
>> consume the new APIs because most don't want to use it in production unless
>> it is declared production ready and we can't call it production ready until
>> someone uses them in production.
>>
>> Having said all that stability and production readiness is paramount for
>> the project.  That is never going to change. In the case of the new APIs,
>> we have developed C++ frameworks using the new APIs and having been running
>> them as part of ASF CI for months now. Mesosphere, for example, also has an
>> internal cluster where frameworks using these new APIs have been baking for
>> a while and had done (and doing) rigorous tests (network partitions,
>> scaling tests, functional tests). Community members from IBM have also been
>> instrumental in testing the new APIs. We are hoping after 1.0 more people
>> would be willing and excited to consume these new APIs and stress test in
>> their environments.
>>
>> At the end of the day, while new APIs are an important part of Mesos 1.0
>> it's not the only reason for cutting a 1.0 release. Mesos has a slew of
>> exciting features and a thriving eco system and we would love to have more
>> people excited and get a taste of it. 1.0 is just a start...
>>
>> Hope that helps,
>>
>>
>> On Wed, May 25, 2016 at 4:57 PM, Zameer Manji  wrote:
>>
>>> I might be in the minority here, but I think cutting an RC for 1.0 right
>>> now is very aggressive. Does there exist even a single framework that
>>> uses
>>> the Scheduler HTTP API or the Executor HTTP API? Does anyone even use
>>> these
>>> APIs in production? Is there a single entity that uses the Operator API
>>> to
>>> manage agents?
>>>
>>> I think cutting an RC right now is 100% premature until the community can
>>> provide clear answers to these questions.
>>>
>>> I think Mesos project has been historically successful because its
>>> features
>>> were developed in a slow methodical manner and then battle tested by at
>>> least a user before the feature was declared 'stable' and ready for use
>>> for
>>> everyone. I think not following those steps here for the HTTP APIs is a
>>> huge error.
>>>
>>> On Wed, May 25, 2016 at 12:51 PM, Vinod Kone 
>>> wrote:
>>>
>>> > Post 1.0. Jie might be able to shed more light regarding the plans for
>>> > Docker Containerizer.
>>> >
>>> > On Wed, May 25, 2016 at 12:10 PM, Jeff Schroeder <
>>> > jeffschroe...@computer.org> wrote:
>>> >
>>> >> Does this mean the work to deprecate the docker containerizer will be
>>> >> post-1.0, or have those plans changed?
>>> >>
>>> >>
>>> >> On Wednesday, May 25, 2016, Vinod Kone  wrote:
>>> >>
>>> >>> Hi folks,
>>> >>>
>>> >>> As discussed in the previous community sync, we plan to cut a release
>>> >>> candidate for our next release (1.0) early next week.
>>> >>>
>>> >>> 1.0 is mainly centered around new APIs for Mesos. Please take a look
>>> 

Re: 1.0 Release Candidate

[Vinod Kone]

This is the release dashboard:

https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12328255

*NOTE: *If you have set a Fix Version of 0.29.0 on a ticket that is not a
blocker for 0.29.0/1.0 release, please unset the fix version.

On Thu, May 26, 2016 at 3:44 PM, Vinod Kone  wrote:

> Thanks for asking the questions Zameer. Wanted to give some clarification
> regarding the thought process for releasing 1.0.
>
> The reason for cutting  a 1.0, is because we want to signal that the Mesos
> project has reached a level of maturity to the wider community. Among other
> things we are confident at this point that the *foundations* we laid for
> the new APIs are mature and could be evolved in a backwards compatible way.
> We laid the foundations almost an year ago (at last MesosCon) and since
> then have been busy implementing the backend to drive the API.  Even the
> newly released design doc for the operator API is built on the same
> foundations as the scheduler/executor APIs. While we have been tweaking the
> API backend for a while now the API definitions have mostly stayed the
> same. Part of the reason it took this long is because we really wanted to
> be sure the basic building blocks were solid.
>
> MesosCon is a great opportunity for us to drum up excitement about the new
> APIs and invite them to start using/testing it. Like any other OSS project,
> as people and organizations start using the new APIs in staging and
> production, we will make stability and implementation improvements. The
> long period for the RC will also help catching issues with API foundations
> themselves. We have had a bit of chicken and egg problem having people
> consume the new APIs because most don't want to use it in production unless
> it is declared production ready and we can't call it production ready until
> someone uses them in production.
>
> Having said all that stability and production readiness is paramount for
> the project.  That is never going to change. In the case of the new APIs,
> we have developed C++ frameworks using the new APIs and having been running
> them as part of ASF CI for months now. Mesosphere, for example, also has an
> internal cluster where frameworks using these new APIs have been baking for
> a while and had done (and doing) rigorous tests (network partitions,
> scaling tests, functional tests). Community members from IBM have also been
> instrumental in testing the new APIs. We are hoping after 1.0 more people
> would be willing and excited to consume these new APIs and stress test in
> their environments.
>
> At the end of the day, while new APIs are an important part of Mesos 1.0
> it's not the only reason for cutting a 1.0 release. Mesos has a slew of
> exciting features and a thriving eco system and we would love to have more
> people excited and get a taste of it. 1.0 is just a start...
>
> Hope that helps,
>
>
> On Wed, May 25, 2016 at 4:57 PM, Zameer Manji  wrote:
>
>> I might be in the minority here, but I think cutting an RC for 1.0 right
>> now is very aggressive. Does there exist even a single framework that uses
>> the Scheduler HTTP API or the Executor HTTP API? Does anyone even use
>> these
>> APIs in production? Is there a single entity that uses the Operator API to
>> manage agents?
>>
>> I think cutting an RC right now is 100% premature until the community can
>> provide clear answers to these questions.
>>
>> I think Mesos project has been historically successful because its
>> features
>> were developed in a slow methodical manner and then battle tested by at
>> least a user before the feature was declared 'stable' and ready for use
>> for
>> everyone. I think not following those steps here for the HTTP APIs is a
>> huge error.
>>
>> On Wed, May 25, 2016 at 12:51 PM, Vinod Kone 
>> wrote:
>>
>> > Post 1.0. Jie might be able to shed more light regarding the plans for
>> > Docker Containerizer.
>> >
>> > On Wed, May 25, 2016 at 12:10 PM, Jeff Schroeder <
>> > jeffschroe...@computer.org> wrote:
>> >
>> >> Does this mean the work to deprecate the docker containerizer will be
>> >> post-1.0, or have those plans changed?
>> >>
>> >>
>> >> On Wednesday, May 25, 2016, Vinod Kone  wrote:
>> >>
>> >>> Hi folks,
>> >>>
>> >>> As discussed in the previous community sync, we plan to cut a release
>> >>> candidate for our next release (1.0) early next week.
>> >>>
>> >>> 1.0 is mainly centered around new APIs for Mesos. Please take a look
>> at
>> >>> MESOS-338  for
>> >>> blocking issues. We got some great design and testing feedback for
>> the v1
>> >>> scheduler and executor APIs. Please do the same for the in-progress v1
>> >>> operator API
>> >>> <
>> https://docs.google.com/document/d/1XfgF4jDXZDVIEWQPx6Y4glgeTTswAAxw6j8dPDAtoeI/edit?pref=2=1#
>> >
>> >>> .
>> >>>
>> >>> Since this is a 1.0, we would like to do the release a little
>> 

Re: 1.0 Release Candidate

[Vinod Kone]

Thanks for asking the questions Zameer. Wanted to give some clarification
regarding the thought process for releasing 1.0.

The reason for cutting  a 1.0, is because we want to signal that the Mesos
project has reached a level of maturity to the wider community. Among other
things we are confident at this point that the *foundations* we laid for
the new APIs are mature and could be evolved in a backwards compatible way.
We laid the foundations almost an year ago (at last MesosCon) and since
then have been busy implementing the backend to drive the API.  Even the
newly released design doc for the operator API is built on the same
foundations as the scheduler/executor APIs. While we have been tweaking the
API backend for a while now the API definitions have mostly stayed the
same. Part of the reason it took this long is because we really wanted to
be sure the basic building blocks were solid.

MesosCon is a great opportunity for us to drum up excitement about the new
APIs and invite them to start using/testing it. Like any other OSS project,
as people and organizations start using the new APIs in staging and
production, we will make stability and implementation improvements. The
long period for the RC will also help catching issues with API foundations
themselves. We have had a bit of chicken and egg problem having people
consume the new APIs because most don't want to use it in production unless
it is declared production ready and we can't call it production ready until
someone uses them in production.

Having said all that stability and production readiness is paramount for
the project.  That is never going to change. In the case of the new APIs,
we have developed C++ frameworks using the new APIs and having been running
them as part of ASF CI for months now. Mesosphere, for example, also has an
internal cluster where frameworks using these new APIs have been baking for
a while and had done (and doing) rigorous tests (network partitions,
scaling tests, functional tests). Community members from IBM have also been
instrumental in testing the new APIs. We are hoping after 1.0 more people
would be willing and excited to consume these new APIs and stress test in
their environments.

At the end of the day, while new APIs are an important part of Mesos 1.0
it's not the only reason for cutting a 1.0 release. Mesos has a slew of
exciting features and a thriving eco system and we would love to have more
people excited and get a taste of it. 1.0 is just a start...

Hope that helps,


On Wed, May 25, 2016 at 4:57 PM, Zameer Manji  wrote:

> I might be in the minority here, but I think cutting an RC for 1.0 right
> now is very aggressive. Does there exist even a single framework that uses
> the Scheduler HTTP API or the Executor HTTP API? Does anyone even use these
> APIs in production? Is there a single entity that uses the Operator API to
> manage agents?
>
> I think cutting an RC right now is 100% premature until the community can
> provide clear answers to these questions.
>
> I think Mesos project has been historically successful because its features
> were developed in a slow methodical manner and then battle tested by at
> least a user before the feature was declared 'stable' and ready for use for
> everyone. I think not following those steps here for the HTTP APIs is a
> huge error.
>
> On Wed, May 25, 2016 at 12:51 PM, Vinod Kone  wrote:
>
> > Post 1.0. Jie might be able to shed more light regarding the plans for
> > Docker Containerizer.
> >
> > On Wed, May 25, 2016 at 12:10 PM, Jeff Schroeder <
> > jeffschroe...@computer.org> wrote:
> >
> >> Does this mean the work to deprecate the docker containerizer will be
> >> post-1.0, or have those plans changed?
> >>
> >>
> >> On Wednesday, May 25, 2016, Vinod Kone  wrote:
> >>
> >>> Hi folks,
> >>>
> >>> As discussed in the previous community sync, we plan to cut a release
> >>> candidate for our next release (1.0) early next week.
> >>>
> >>> 1.0 is mainly centered around new APIs for Mesos. Please take a look at
> >>> MESOS-338  for
> >>> blocking issues. We got some great design and testing feedback for the
> v1
> >>> scheduler and executor APIs. Please do the same for the in-progress v1
> >>> operator API
> >>> <
> https://docs.google.com/document/d/1XfgF4jDXZDVIEWQPx6Y4glgeTTswAAxw6j8dPDAtoeI/edit?pref=2=1#
> >
> >>> .
> >>>
> >>> Since this is a 1.0, we would like to do the release a little
> >>> differently.
> >>>
> >>> First, the voting period for vetting the release candidate would be a
> >>> few weeks (2-3 weeks) instead of the typical 3 days.
> >>>
> >>> Second, we are wiling to make major changes (scalability fixes, API
> >>> fixes) if there are any issues reported by the community.
> >>>
> >>> We are doing these because we really want the community to thoroughly
> >>> test the 1.0 release and give feedback.
> >>>
> >>> Thanks,
> >>>
> >>
> >>

Re: 1.0 Release Candidate

[Zameer Manji]

I might be in the minority here, but I think cutting an RC for 1.0 right
now is very aggressive. Does there exist even a single framework that uses
the Scheduler HTTP API or the Executor HTTP API? Does anyone even use these
APIs in production? Is there a single entity that uses the Operator API to
manage agents?

I think cutting an RC right now is 100% premature until the community can
provide clear answers to these questions.

I think Mesos project has been historically successful because its features
were developed in a slow methodical manner and then battle tested by at
least a user before the feature was declared 'stable' and ready for use for
everyone. I think not following those steps here for the HTTP APIs is a
huge error.

On Wed, May 25, 2016 at 12:51 PM, Vinod Kone  wrote:

> Post 1.0. Jie might be able to shed more light regarding the plans for
> Docker Containerizer.
>
> On Wed, May 25, 2016 at 12:10 PM, Jeff Schroeder <
> jeffschroe...@computer.org> wrote:
>
>> Does this mean the work to deprecate the docker containerizer will be
>> post-1.0, or have those plans changed?
>>
>>
>> On Wednesday, May 25, 2016, Vinod Kone  wrote:
>>
>>> Hi folks,
>>>
>>> As discussed in the previous community sync, we plan to cut a release
>>> candidate for our next release (1.0) early next week.
>>>
>>> 1.0 is mainly centered around new APIs for Mesos. Please take a look at
>>> MESOS-338  for
>>> blocking issues. We got some great design and testing feedback for the v1
>>> scheduler and executor APIs. Please do the same for the in-progress v1
>>> operator API
>>> 
>>> .
>>>
>>> Since this is a 1.0, we would like to do the release a little
>>> differently.
>>>
>>> First, the voting period for vetting the release candidate would be a
>>> few weeks (2-3 weeks) instead of the typical 3 days.
>>>
>>> Second, we are wiling to make major changes (scalability fixes, API
>>> fixes) if there are any issues reported by the community.
>>>
>>> We are doing these because we really want the community to thoroughly
>>> test the 1.0 release and give feedback.
>>>
>>> Thanks,
>>>
>>
>>
>> --
>> Text by Jeff, typos by iPhone
>>
>
>

Re: 1.0 Release Candidate

[Jeff Schroeder]

Does this mean the work to deprecate the docker containerizer will be
post-1.0, or have those plans changed?

On Wednesday, May 25, 2016, Vinod Kone  wrote:

> Hi folks,
>
> As discussed in the previous community sync, we plan to cut a release
> candidate for our next release (1.0) early next week.
>
> 1.0 is mainly centered around new APIs for Mesos. Please take a look at
> MESOS-338  for blocking
> issues. We got some great design and testing feedback for the v1 scheduler
> and executor APIs. Please do the same for the in-progress v1 operator API
> 
> .
>
> Since this is a 1.0, we would like to do the release a little differently.
>
> First, the voting period for vetting the release candidate would be a few
> weeks (2-3 weeks) instead of the typical 3 days.
>
> Second, we are wiling to make major changes (scalability fixes, API fixes)
> if there are any issues reported by the community.
>
> We are doing these because we really want the community to thoroughly test
> the 1.0 release and give feedback.
>
> Thanks,
>


-- 
Text by Jeff, typos by iPhone

Re: 1.0 Release Candidate

[Vinod Kone]

Post 1.0. Jie might be able to shed more light regarding the plans for
Docker Containerizer.

On Wed, May 25, 2016 at 12:10 PM, Jeff Schroeder  wrote:

> Does this mean the work to deprecate the docker containerizer will be
> post-1.0, or have those plans changed?
>
>
> On Wednesday, May 25, 2016, Vinod Kone  wrote:
>
>> Hi folks,
>>
>> As discussed in the previous community sync, we plan to cut a release
>> candidate for our next release (1.0) early next week.
>>
>> 1.0 is mainly centered around new APIs for Mesos. Please take a look at
>> MESOS-338  for blocking
>> issues. We got some great design and testing feedback for the v1 scheduler
>> and executor APIs. Please do the same for the in-progress v1 operator API
>> 
>> .
>>
>> Since this is a 1.0, we would like to do the release a little
>> differently.
>>
>> First, the voting period for vetting the release candidate would be a few
>> weeks (2-3 weeks) instead of the typical 3 days.
>>
>> Second, we are wiling to make major changes (scalability fixes, API
>> fixes) if there are any issues reported by the community.
>>
>> We are doing these because we really want the community to thoroughly
>> test the 1.0 release and give feedback.
>>
>> Thanks,
>>
>
>
> --
> Text by Jeff, typos by iPhone
>

Re: 1.0 Release Candidate

[Jie Yu]

Jeff,

Yes, deprecating the docker containerizer will be post-1.0. The plan has
not changed. In fact, we are making very good progress on the unified
containerizer side (see this doc
).

We'll continue to support Docker containerizer, but at a reduced pace. In
other words, any new features will be supported in the unified
containerizer first. We will still do bug fixes for the docker
containerizer.

Let us know if you have any comments or concerns on that. Thanks!

- Jie

On Wed, May 25, 2016 at 12:10 PM, Jeff Schroeder  wrote:

> Does this mean the work to deprecate the docker containerizer will be
> post-1.0, or have those plans changed?
>
>
> On Wednesday, May 25, 2016, Vinod Kone  wrote:
>
>> Hi folks,
>>
>> As discussed in the previous community sync, we plan to cut a release
>> candidate for our next release (1.0) early next week.
>>
>> 1.0 is mainly centered around new APIs for Mesos. Please take a look at
>> MESOS-338  for blocking
>> issues. We got some great design and testing feedback for the v1 scheduler
>> and executor APIs. Please do the same for the in-progress v1 operator API
>> 
>> .
>>
>> Since this is a 1.0, we would like to do the release a little
>> differently.
>>
>> First, the voting period for vetting the release candidate would be a few
>> weeks (2-3 weeks) instead of the typical 3 days.
>>
>> Second, we are wiling to make major changes (scalability fixes, API
>> fixes) if there are any issues reported by the community.
>>
>> We are doing these because we really want the community to thoroughly
>> test the 1.0 release and give feedback.
>>
>> Thanks,
>>
>
>
> --
> Text by Jeff, typos by iPhone
>

Re: 1.0 Release Candidate

[Joseph Wu]

I'm guessing you mean the "medium term" bullet point on the Roadmap (
https://cwiki.apache.org/confluence/display/MESOS/Roadmap):

>
>- Deprecate Docker containerizer (in favor of Unified containerizer w/
>Docker support)
>
> This was never meant to be done as part of the 1.0 release.  I'm sure the
folks working on the unified containerizer can tell you their exact plans.


On Wed, May 25, 2016 at 12:10 PM, Jeff Schroeder  wrote:

> Does this mean the work to deprecate the docker containerizer will be
> post-1.0, or have those plans changed?
>
>
> On Wednesday, May 25, 2016, Vinod Kone  wrote:
>
>> Hi folks,
>>
>> As discussed in the previous community sync, we plan to cut a release
>> candidate for our next release (1.0) early next week.
>>
>> 1.0 is mainly centered around new APIs for Mesos. Please take a look at
>> MESOS-338  for blocking
>> issues. We got some great design and testing feedback for the v1 scheduler
>> and executor APIs. Please do the same for the in-progress v1 operator API
>> 
>> .
>>
>> Since this is a 1.0, we would like to do the release a little
>> differently.
>>
>> First, the voting period for vetting the release candidate would be a few
>> weeks (2-3 weeks) instead of the typical 3 days.
>>
>> Second, we are wiling to make major changes (scalability fixes, API
>> fixes) if there are any issues reported by the community.
>>
>> We are doing these because we really want the community to thoroughly
>> test the 1.0 release and give feedback.
>>
>> Thanks,
>>
>
>
> --
> Text by Jeff, typos by iPhone
>

Re: 1.0 Release Candidate

[Vinod Kone]

As part of this, I'm going to:

1) Update configure.ac and CMakeLists to point to 1.0.0 version. Note that
if someone is building off master, this might be a little weird because up
until this change their builds would've 0.29.0 version and after this
change it would be 1.0.0. But I guess it's unavoidable.

2) Transition the issues with Fix Version "0.29.0" to "1.0.0". I will make
sure to turn off JIRA notification emails for this change to avoid spamming
issues@.

Thanks,

On Wed, May 25, 2016 at 8:52 AM, Vinod Kone  wrote:

> Hi folks,
>
> As discussed in the previous community sync, we plan to cut a release
> candidate for our next release (1.0) early next week.
>
> 1.0 is mainly centered around new APIs for Mesos. Please take a look at
> MESOS-338  for blocking
> issues. We got some great design and testing feedback for the v1 scheduler
> and executor APIs. Please do the same for the in-progress v1 operator API
> 
> .
>
> Since this is a 1.0, we would like to do the release a little differently.
>
> First, the voting period for vetting the release candidate would be a few
> weeks (2-3 weeks) instead of the typical 3 days.
>
> Second, we are wiling to make major changes (scalability fixes, API fixes)
> if there are any issues reported by the community.
>
> We are doing these because we really want the community to thoroughly test
> the 1.0 release and give feedback.
>
> Thanks,
>

1.0 Release Candidate

[Vinod Kone]

Hi folks,

As discussed in the previous community sync, we plan to cut a release
candidate for our next release (1.0) early next week.

1.0 is mainly centered around new APIs for Mesos. Please take a look at
MESOS-338  for blocking
issues. We got some great design and testing feedback for the v1 scheduler
and executor APIs. Please do the same for the in-progress v1 operator API

.

Since this is a 1.0, we would like to do the release a little differently.

First, the voting period for vetting the release candidate would be a few
weeks (2-3 weeks) instead of the typical 3 days.

Second, we are wiling to make major changes (scalability fixes, API fixes)
if there are any issues reported by the community.

We are doing these because we really want the community to thoroughly test
the 1.0 release and give feedback.

Thanks,