> SAI will follow the same QA/Testing guideline as in CASSANDRA-15536.
CASSANDRA-15536 might set some good examples for retrospectively shoring up our
quality assurance, but offers no prescriptions for how we approach the testing
of new work. I think the project needs to conclude the discussions that keep
being started around the "definition of done" before determining what
sufficient quality assurance looks like for this feature.
I've briefly set out some of my views in an earlier email chain that was
initiated by Josh, that unfortunately received no response. The project is
generally very busy right now as we approach 4.0 release, which is partially I
assume why there has been no movement. Assuming no further activity from
others, as we get closer to 4.0 (and I have more time) I will try to produce a
more formal proposal for quality assurance for the project, to be debated and
agreed.
On 18/08/2020, 12:02, "Jasonstack Zhao Yang" <jasonstack.z...@gmail.com> wrote:
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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
