> If we have automated, more-than-nightly composes that look much like a > regular release compose would, there's no clear case for having TCs at > all. We could simply stop building them and extend the "nightly" > validation process. I think the way to do that would be to keep > 'nominating' nightly composes for validation testing all the time, > *except* when we're doing RCs. So instead of going something like: > > 24 Rawhide 20160120 > 24 Rawhide 20160215 > == BRANCH POINT == > 24 Branched 20160301 > 24 Branched 20160315 > 24 Alpha TC1 > 24 Alpha TC2 > == ALPHA FREEZE == > 24 Alpha RC1 > 24 Alpha RC2 > == ALPHA RELEASE == > 24 Beta TC1 > .... > > we'd go something like: > > 24 Rawhide 20160120 > 24 Rawhide 20160215 > == BRANCH POINT == > 24 > Branched 20160301 > 24 Branched 20160315 > 24 Branched 20160401 > 24 Alpha RC1 > 24 > Alpha RC2 > == ALPHA RELEASE == > 24 Branched 20160501 > 24 Branched > 20160515 > 24 Beta RC1 > .... Here's a question. Are we going to "nominate" only those composes in which a substantial component changed (i.e. anaconda or systemd), similarly to what we do now in rawhide, or are we going to nominate each new compose (i.e. one or more per day)? The first approach seems simpler for humans, but I can't imagine how we make it work for e.g. Desktop matrices - there's so many components in there that we would probably end up nominating every day anyway. The second approach means we would let automation do its job and humans would have to rely mainly on testcase_stats to see which test cases were recently tested and which were not, and test according to that. I think the second approach is something that we should aim for in the future, but I'm not sure we're there yet. It will certainly require some larger changes in testcase_stats to make sure they correctly represent everything (now that we'll rely solely on that), e.g. not squashing different test environments together into a single result, etc. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
