Hi Sean, for what I understood, we will need a new feature flag for each new feature, and a feature flag (default to false) for each deprecated one. My concern is: since the goal is make tempest a confident tool to test any installation and not and 'tempest.conf' will not be auto-generated from any tool as devstack does, wouldn't be too hard to prepare a tempest.conf file with so many feature flags to enable and disable?
Maybe I am simplifying too much, but wouldn't be enough with a pair of functions decorators like @new @deprecated Then, in tempest.conf it could be a flag to say which OpenStack installation are you testing: installation = [icehouse|juno] if you choose Juno, tests with @new decorator will be executed and tests with @deprecated will be skipped. If you choose Icehouse, tests with @new decorator will be skipped, and tests with @deprecated will be executed I am missing some obvious case that make this approach a nonsense? Regards, jaume On 14 April 2014 15:21, Sean Dague <s...@dague.net> wrote: > As we're coming up on the stable/icehouse release the QA team is looking > pretty positive at no longer branching Tempest. The QA Spec draft for > this is here - > > http://docs-draft.openstack.org/77/86577/2/check/gate-qa-specs-docs/3f84796/doc/build/html/specs/branchless-tempest.html > and hopefully address a lot of the questions we've seen so far. > > Additional comments are welcome on the review - > https://review.openstack.org/#/c/86577/ > or as responses on this ML thread. > > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > http://dague.net > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
