Finish the roadmap

content/blog/2022-v0.7-released.md

@@ -265,16 +265,19 @@ In all cases, your feedback is welcome on our Matrix channel.
 ## And next?
 
 While we hope that Garage in its current state inspired you, we also understand that you may be curious about what will come next!
-Currently, our goal is to reach v1.0, for which we want to work on these three desirable properties: *Feature complete*, *Understandability and manageability*, and *Correctness*.
+Currently, our goal is to reach v1.0, for which we want to work on these three desirable properties: *Feature completeness*, *Understandability and manageability*, and *Correctness*.
 
-**Feature complete**. We have already implemented a selected subset of S3 endpoints that works quite well, but we want to work on the corner cases that are not yet solved (eg. [#263](https://git.deuxfleurs.fr/Deuxfleurs/garage/issues), [#248](https://git.deuxfleurs.fr/Deuxfleurs/garage/issues/248), [#204](https://git.deuxfleurs.fr/Deuxfleurs/garage/issues/204). Based on community feedbacks, we might consider implementing additional endpoints (eg. [#166](https://git.deuxfleurs.fr/Deuxfleurs/garage/issues/166) but we can make no promise (sorry!). Finally, we made a serie of observation: 1) the S3 API has a limited semantic, for example it is not adapted for append-only log data structures, 2) many projects require a database additionaly to the object store 3) we already implemented a key value store internally to handle S3 metadata. It leads us to the conclusion that we study the feasibility of providing a simple and totally optional key value interface that we refer as K2V. We are currently writing [an API draft](https://p.adnab.me/code/#/2/code/view/eUNPbfoUrMbCY+CoMXaqed4jmWlmvWALHNDcfuM-O5o/embed/present/) and will try to implement it in the following months. We would like it to be as close as possible as the original [Amazon Dynamo paper](https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf), or if you are more familiar with Cassandra, as the most possible minimalistic Cassandra.
+**Feature completeness**. We have already implemented a selected subset of S3 endpoints that works quite well, but we want to work on the corner cases that are not yet solved (eg. [#263](https://git.deuxfleurs.fr/Deuxfleurs/garage/issues), [#248](https://git.deuxfleurs.fr/Deuxfleurs/garage/issues/248), [#204](https://git.deuxfleurs.fr/Deuxfleurs/garage/issues/204). Based on community feedbacks, we might consider implementing additional endpoints (eg. [#166](https://git.deuxfleurs.fr/Deuxfleurs/garage/issues/166) but we can't make any promise (sorry!). Finally, we made a serie of observation: 1) the S3 API has a limited semantic, for example it is not adapted for append-only log data structures, 2) many projects require a database additionaly to the object store, and 3) we already implemented a key value store internally to handle S3 metadata. Following these observations, we want to study the feasibility of providing a simple and totally optional key value interface that we refer to as K2V. We are currently writing [an API draft](https://p.adnab.me/code/#/2/code/view/eUNPbfoUrMbCY+CoMXaqed4jmWlmvWALHNDcfuM-O5o/embed/present/) and will try to implement it in the following months. We would like it to be as close as possible as the original [Amazon Dynamo paper](https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf), or if you like approximative comparisons, K2V could be to Cassandra what sqlite is to PostgreSQL.
 
-**Understandability and manageability**. We want a system that is understood and manageable by the largest possible amount of operators. To achieve such a goal, we can follow 2 paths: sharing knowledge and making better tools. We want to explore both approaches, and we identified specific subjects on which to work: 1) Garage's consistency model of the S3 API and the admin API, 2) Explaining how Garage can take its place in the existing ecosystem, including among the other distributed storage systems, but also in term of uses cases and business 
+**Understandability and manageability**. We want a system that is understood and manageable by the largest possible amount of operators. We identified the following points that we would like to improve: 1) Explaining Garage's consistency model, both on the S3 and the admin API, 2) Explaining how Garage can take its place in the existing ecosystem, including among the other distributed storage systems (eg. Ceph, Minio, SeaweedFS, IPFS Cluster), but also in term of uses cases and deployments (how does it perform at scale, with which hardware, for which application, etc.) 3) Make possible to manage Garage from a REST API, possibly write a web GUI to make administration easier, 4) help people understand the reliability and storage density they will have for a specific Garage deployment, if possible through a simulator, 5) we might consider adding a system of quota to protect a cluster from a misbehaving user.
+
+**Correctness**. We know in theory that Garage's design works and scales. 
+But we still need to make sure that in practise our implementation is correct, and thus features these defined properties.
+To convince ourselves, we consider verifying our consistency model implementation through [Jepsen](https://jepsen.io/).
+We also plan to deploy Garage on multiple clusters and do a large serie of benchmarks.
+
+Please note that this roadmap is purely indicative, we are not committing to deliver these features.
+We also don't know when v1.0 will be released, except "when it will be ready", but we would be happy if it could be by the end of 2022.
+Finally, if you have some knowledge on one or more of thes points and would like to help, feel free to ping us on Matrix.
+And see you soon for the next release!
 
-  - Well understood, well explained
-    - Consistency Model
-    - Deployment Cas Typique
-    - web interface, rest admin
-    - Storage density vs reliability, deployment simulator 
-  - Fast, tested and correct
-    -