I believe this will be very useful for users. As far as I understand someone will have to qualify components. What will be the method for qualification? I do not think simply the test coverage would be right. But then if you want to go deeper, then you need a bigger effort testing the components.
On Sun, Oct 27, 2013 at 4:51 PM, Darren Shepherd < darren.s.sheph...@gmail.com> wrote: > I don't know if a similar thing has been talked about before but I > thought I'd just throws this out there. The ultimate way to ensure > quality is that we have unit test and integration test coverage on all > functionality. That way somebody authors some code, commits to, for > example, 4.2, but then when we release 4.3, 4.4, etc they aren't on > the hook to manually tests the functionality with each release. The > obvious nature of a community project is that people come and go. If > a contributor wants to ensure the long term viability of the > component, they should ensure that there are unit+integration tests. > > Now, for whatever reason whether good or bad, it's not always possible > to have full integration tests. I don't want to throw down the gamut > and say everything must have coverage because that will mean some > useful code/feature will not get in because of some coverage wasn't > possible at the time. > > What I propose is that for every feature or function we put it in a > tier of what is the quality of it (very similar to how OpenStack > qualifies their hypervisor integration). Tier A means unit test and > integration test coverage gates the release. Tier B means unit test > coverage gates the release. Tier C mean who knows, it compiled. We > can go through and classify the components and then as a community we > can try to get as much into Tier A as possible. > > Darren > -- EOF
