On 20/08/2012, at 10:02 PM, Mike Burns wrote: > Hi all, > > Now that oVirt 3.1 has shipped, we need to start the planning process > for the next release. One of the major topics for this week's weekly > sync is to review the release criteria. > > The criteria we used for 3.1 is laid out on the wiki [1]. I will be > posting an equivalent version for the next release in the next couple > days, but it will mostly be copy/paste from this page. > > Please think about release criteria and whether or not we want to > add/remove/change things for this release. This needs to be determined > now to make sure that the release process runs smoother down the line. Is there some way we can do an end-to-end platform test for most of the things mentioned there, to sanity check the binaries before announcement? Trying to think of some way to catch the "broken ISO" problem that 3.1 has with NFS storage. So, something similar doesn't occur again in future. Any ideas?

Regards and best wishes, Justin Clift > Thanks > > Mike > > [1] http://wiki.ovirt.org/wiki/Second_Release > > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users -- Aeolus Community Manager http://www.aeolusproject.org _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

* Mike Burns <mburns(a)redhat.com&gt; [2012-08-21 07:29]: > On Tue, 2012-08-21 at 19:52 +1000, Justin Clift wrote: > > On 20/08/2012, at 10:02 PM, Mike Burns wrote: > > > Hi all, > > > > > > Now that oVirt 3.1 has shipped, we need to start the planning process > > > for the next release. One of the major topics for this week's weekly > > > sync is to review the release criteria. > > > > > > The criteria we used for 3.1 is laid out on the wiki [1]. I will be > > > posting an equivalent version for the next release in the next couple > > > days, but it will mostly be copy/paste from this page. > > > > > > Please think about release criteria and whether or not we want to > > > add/remove/change things for this release. This needs to be determined > > > now to make sure that the release process runs smoother down the line. > > > > Is there some way we can do an end-to-end platform test for most > > of the things mentioned there, to sanity check the binaries before > > announcement? > > > > Trying to think of some way to catch the "broken ISO" problem that 3.1 > > has with NFS storage. So, something similar doesn't occur again in > > future. > > > > Any ideas? > > Yes, this makes a lot of sense to me. We should make an end-to-end > sanity test with all components part of the release criteria. I haven't seen much discussion around testing the complete stack as a whole. I'm wondering if the all-in-one build makes a good platform to build stack testing against? I don't really enjoying fixing up jboss or selinux or various other tweaks on test day when installing from scratch (though that does find some bugs), so all-in-one seems like a good sanity check. From there, building/writing some tests using either engine-cli, or the ovirt-sdk python bindings seems like a good way to exercise the function of the release. With the nested mode supported, would it be possible to have a jenkins job run a test that booted the all-in-one iso and ran some tests against that?

> > Mike > > > > > Regards and best wishes, > > > > Justin Clift > > > > > Thanks > > > > > > Mike > > > > > > [1] http://wiki.ovirt.org/wiki/Second_Release > > > > > > > > > _______________________________________________ > > > Users mailing list > > > Users(a)ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/users > > > > -- > > Aeolus Community Manager > > http://www.aeolusproject.org > > > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > > _______________________________________________ > Board mailing list > Board(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/board