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 > >>> >> > >>> > > >>> > > >>> > >> > >> > >
