Mick thanks for your questions. > During the 4.0 beta phase this was intended to be addressed, i.e.> defining more specific QA guidelines for 4.0-rc. This would be an important > step towards QA guidelines for all changes and CEPs post-4.0.
Agreed, I think CASSANDRA-15536 <https://issues.apache.org/jira/browse/CASSANDRA-15536> (4.0 Quality: Components and Test Plans) has set a good example of QA/Testing. > - How will this be tested, how will its QA status and lifecycle be> defined? (per above) SAI will follow the same QA/Testing guideline as in CASSANDRA-15536. > - With existing C* code needing to be changed, what is the proposed plan> for making those changes ensuring maintained QA, e.g. is there separate QA > cycles planned for altering the SPI before adding a new SPI implementation? The plan is to have interface changes and their new implementations to be reviewed/tested/merged at once to reduce overhead. But if having interface changes reviewed/tested/merged separately helps quality, I don't think anyone will object. > - Despite being out of scope, it would be nice to have some idea from the> CEP author of when users might still choose afresh 2i or SASI over SAI I'd like SAI to be the only index for users, but this is a decision to be made by the community. > - Who fills the roles involved? Contributors that are still active on C* or related projects: Andres de la Peña Caleb Rackliffe Dan LaRocque Jason Rutherglen Mike Adamson Rocco Varela Zhao Yang I will shepherd. Anyone that is interested in C* index, feel free to join us at slack #cassandra-sai. > - Is there a preference to use gdoc instead of the project's wiki, and> why? (the CEP process suggest a wiki page, and feedback on why another > approach is considered better helps evolve the CEP process itself) Didn't notice wiki is required. Will port CEP to wiki. On Tue, 18 Aug 2020 at 17:39, Mick Semb Wever <m...@apache.org> wrote: > > > > We are looking forward to the community's feedback and suggestions. > > > > > What comes immediately to mind is testing requirements. It has been > mentioned already that the project's testability and QA guidelines are > inadequate to successfully introduce new features and refactorings to the > codebase. During the 4.0 beta phase this was intended to be addressed, i.e. > defining more specific QA guidelines for 4.0-rc. This would be an important > step towards QA guidelines for all changes and CEPs post-4.0. > > Questions from me > - How will this be tested, how will its QA status and lifecycle be > defined? (per above) > - With existing C* code needing to be changed, what is the proposed plan > for making those changes ensuring maintained QA, e.g. is there separate QA > cycles planned for altering the SPI before adding a new SPI implementation? > - Despite being out of scope, it would be nice to have some idea from the > CEP author of when users might still choose afresh 2i or SASI over SAI, > - Who fills the roles involved? Who are the contributors in this DataStax > team? Who is the shepherd? Are there other stakeholders willing to be > involved? > - Is there a preference to use gdoc instead of the project's wiki, and > why? (the CEP process suggest a wiki page, and feedback on why another > approach is considered better helps evolve the CEP process itself) > > cheers, > Mick >
