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 <[email protected]> wrote: > cool. > > 2016-05-29 19:03 GMT+08:00 haosdent <[email protected]>: > >> +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 >> > > > > -- > Deshi Xiao > Twitter: xds2000 > E-mail: xiaods(AT)gmail.com >
