Kata-zins, TL;DR: We need to start tracking issues closely, clearly define release criteria, track the required missing features (with owners) and I suggest we target release of June 1st. In detail: I think that the requirements document, [1], put together by the organization represents our criteria for 1.0 release, though we can add some more details with respect to what is required for the CRI friendly API (which is in [2]). One of the most common questions I get when talking about Kata is when the 1.0 release will be. I think we’re at a point where we track release gating features and picking a release date. ==Firstly on tracking== To aid in this, I started marking obviously-release-gating issues with the self descriptive label “release-gating”. The key ones can be seen at [3], [4]. I acknowledge more are needed (meeting our testing and documentation requirements, at least). Since we work across a few different repositories, for my own sanity I usually look @ the issues via waffle, [5]. Disclaimer: I’m not saying waffle is what we use for getting an aggregated view (just something easy I use myself), but I am advocating for the consistent use of a few key labels as we itemize and measure ourselves against release, get more involvement from developers and keep things focused. Key labels for issues that I am suggesting we adopt are: * release-gating: feature or bug which must work in our 1.0 release. We should make sure there is agreement from the architecture committee on what is marked release-gating. * bug: unexpected behavior (not a new feature, not an optimization) * feature: new functionality to add * enhancement: optimization or improvement * help wanted: feature/bug/optimization/test which we are looking for owner on * good first issue: An issue which may be a good fit (based on priority and complexity) for something looking to first get involved in the project. These exist today in the github repos we are using. If there’s consensus we can have this documented in kata-containers/documentation. If you have feel a color chosen for label is offensive or if we could use improved labels and/or descriptions, please provide feedback. ==Secondly, on Release== After taking an independent look at the feature list and where we are today, listening to what Kata-users want, I think that June 1st is a good target for our 1.0 release (shortly after open stack summit, where we can have a f2f working “sprint”, still within first half of the year, etc). I’m looking for feedback from the community (and we will need to clarify exact release criteria closely), but I think this is feasible and a good starting point to work towards. To meet this schedule I think we need to make sure that each release-gating feature has a clear owner and we can start tracking on a regular cadence the status of these. I can help track this, though as a starting point we need to be 100% clear who is working on which feature (ie: who is owner of issue, and already working on implementation). I’ll follow up on these details tomorrow in a follow up mail (after the standing developer community meeting @ 7am pacific). Thx, Eric [1] - https://github.com/kata-containers/documentation/blob/master/design/kata-des... [2] - https://github.com/kata-containers/documentation/blob/master/design/kata-api... [3] - https://github.com/kata-containers/runtime/labels/release-gating [4] - https://github.com/kata-containers/packaging/labels/release-gating [5] - https://waffle.io/kata-containers/runtime?search=release-gating