+1s On Sun, May 29, 2016 at 7:01 PM, Klaus Ma <[email protected]> wrote:
> v1.0, exciting :). > > ---- > Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer > Platform OpenSource Technology, STG, IBM GCG > +86-10-8245 4084 | [email protected] | http://k82.me > > > > Date: Sun, 29 May 2016 02:31:47 -0700 > > Subject: Re: 1.0 Release Candidate > > From: [email protected] > > To: [email protected] > > CC: [email protected]; [email protected] > > > > > 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > > >>> 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 < > > >>> > [email protected]> 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 <[email protected]> > 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 <https://issues.apache.org/jira/browse/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&pli=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, > > >>> >>> > > >>> >> > > >>> >> > > >>> >> -- > > >>> >> Text by Jeff, typos by iPhone > > >>> >> > > >>> > > > >>> > > > >>> > > >> > > >> > > > > -- Best Regards, Haosdent Huang
