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. >> >> 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 <zma...@apache.org> 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 <vinodk...@apache.org> >>> 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 <vinodk...@apache.org> 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 >>> >> >>> > >>> > >>> >> >> >
