[ovirt-devel] [ACTION NEEDED] Please fix vdsm build dependencies on master
Hi, looks like VDSM is missing python-ethtool as BuildRequire on EL6 and FC20: http://jenkins.ovirt.org/job/vdsm_master_install-rpm-sanity-fc20_created/352/artifact/exported-artifacts/build.log http://jenkins.ovirt.org/job/vdsm_master_install-rpm-sanity-el6_created/368/artifact/exported-artifacts/build.log Please fix. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ACTION NEEDED] Please fix vdsm build dependencies on master
- Original Message - From: Sandro Bonazzola sbona...@redhat.com To: devel@ovirt.org Sent: Monday, September 15, 2014 1:11:16 PM Subject: [ovirt-devel] [ACTION NEEDED] Please fix vdsm build dependencies on master Hi, looks like VDSM is missing python-ethtool as BuildRequire on EL6 and FC20: Master doesn't have any more dependency for it. Only vdsm-bootstrap, which still has it on the vdsm.spec.in. I'll look at the log. http://jenkins.ovirt.org/job/vdsm_master_install-rpm-sanity-fc20_created/352/artifact/exported-artifacts/build.log http://jenkins.ovirt.org/job/vdsm_master_install-rpm-sanity-el6_created/368/artifact/exported-artifacts/build.log Please fix. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ACTION NEEDED] Please fix vdsm build dependencies on master
Il 15/09/2014 13:26, Antoni Segura Puimedon ha scritto: - Original Message - From: Antoni Segura Puimedon asegu...@redhat.com To: Sandro Bonazzola sbona...@redhat.com Cc: devel@ovirt.org Sent: Monday, September 15, 2014 1:15:53 PM Subject: Re: [ovirt-devel] [ACTION NEEDED] Please fix vdsm build dependencies on master - Original Message - From: Sandro Bonazzola sbona...@redhat.com To: devel@ovirt.org Sent: Monday, September 15, 2014 1:11:16 PM Subject: [ovirt-devel] [ACTION NEEDED] Please fix vdsm build dependencies on master Hi, looks like VDSM is missing python-ethtool as BuildRequire on EL6 and FC20: Master doesn't have any more dependency for it. Only vdsm-bootstrap, which still has it on the vdsm.spec.in. I'll look at the log. I checked and the latest master doesn't have the configure.ac check that would result in this failure. Rebuilding from master, let's see what happens. http://jenkins.ovirt.org/job/vdsm_master_install-rpm-sanity-fc20_created/352/artifact/exported-artifacts/build.log http://jenkins.ovirt.org/job/vdsm_master_install-rpm-sanity-el6_created/368/artifact/exported-artifacts/build.log Please fix. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [RFC] Release process
Adding infra mailing lists to the loop. Il 08/09/2014 11:34, Sandro Bonazzola ha scritto: Il 20/08/2014 10:05, Sandro Bonazzola ha scritto: Hi, while we're near to release 3.5.0 I would like to start the discussion on the release process for 3.5.z and 3.6.0. The reference page for the release process has been last updated 2 years ago and is not reflecting the way we're managing the releases anymore. Following up to this email with proposal for missing bits. Comments are welcome. In order to start the discussion here's what we are currently doing: = oVirt maintenance releases = * After a new 3.y.0 release, maintenance releases are scheduled every month until a new 3.y+1.0 release is published. * After first 3.y.0 release candidate is published a new release management wiki page is created (see http://www.ovirt.org/OVirt_3.4.z_release-management) * For each 3.y.z release, the release management page is updated ** Defining the schedule for RC and GA date ** Pointing to the new release note page to be created (see http://www.ovirt.org/OVirt_3.4.4_Release_Notes) ** Pointing to a testing page to be created (see http://www.ovirt.org/Testing/oVirt_3.4.4_Testing) ** Pointing to a blocker bug to be created (see http://bugzilla.redhat.com/1118689) * Weekly status email are sent to users and devel lists * QA page is updated with pointers to the new release (see http://www.ovirt.org/OVirt_Quality_Assurance) * Release manager update the release notes pages starting from RC Usually RC date is scheduled one week before GA. RC releases are created by taking the latest nightly snapshot available after verifying that the build passes basic sanity test and repository closure. A new stabilization branch is created with the same git hash used for building the snapshot. Between RC and GA release criteria are tested on the RC and if the release met the criteria a GA release will be built just updating the versioning code to drop master, git hash and timestamp suffix from tarballs and rpms. A new RC will be created and GA postponed by one week if release criteria are not met. = oVirt Release Process = * After a new 3.y.0 release, a new 3.y+1.0 release is tentatively scheduled after 6 months. * A new release management page is created (see http://www.ovirt.org/OVirt_3.5_release-management) * A new tracker bug is created (see http://bugzilla.redhat.com/1073943) * A discussion is started on devel and users mailing list gathering idea for next release features * Teams prepare a list of accepted features collecting / creating bug tracker, devel owner, qa owner, feature page for each of them * Several presentations are scheduled by the teams presenting the accepted features * An alpha release is scheduled 4 months before GA * Feature freeze is scheduled 3 months before GA * A beta release is scheduled 2 months before GA, git tree is branched for stabilization * A release candidate is scheduled 1 month before GA * Weekly status email are sent starting 3 weeks before alpha release. * Test days are scheduled after every milestone release * Release manager update the release notes pages starting from Alpha All milestones releases are created by taking the latest nightly snapshot available after verifying that the build passes basic sanity test and repository closure. RC will be postponed until all known blockers are fixed Between RC and GA release criteria are tested on the RC and if the release met the criteria a GA release will be built just updating the versioning code to drop master, git hash and timestamp suffix from tarballs and rpms. A new RC will be created and GA postponed by one week if release criteria are not met. [[Category:Release management]] What I think we're missing / doing wrong: * A discussion about release criteria *after* accepted features list is ready 1) I think we should require that each feature must come with a set of test cases covering the functionality provided by the new feature. The test cases becomes part of the release criteria as * All test cases defined for each accepted feature must be verified and pass the test for the build to be released This means that the whole test suite must be verified on each release candidate for deciding if it's ready to be released. Test suite should cover whatever is in the documentation of the feature. This means that the feature must contain enough documentation to be considered a contract between the feature owner and the feature tester / user. 2) I think that the current criteria: MUST: No blockers on the lower level components - libvirt, lvm,device-mapper,qemu-kvm, Jboss, postgres, iscsi-initiator should be dropped. We're not acting as QA for lower level components. Instead I think we should change above statement with: MUST: all lower level components must be available on supported distributions at required version
[ovirt-devel] [ANN] oVirt 3.5 Third Test Day - Wed Sep 17th
Hi all, On Wed Sep 17th (instead of Sep 16th) we'll have oVirt 3.5.0 third test day. On this day all relevant engineers will be online ready to support any issues you find during install / operating this new release. Just make sure you have 1 host or more to test drive the new release. If you're curious to see how it works, this is your chance. Thanks again for everyone who will join us tomorrow! Location #ovirt irc channel Please communicate here to allow others to see any issues What In this test day you have a license to kill ;) Follow the documentation to setup your environment, and test drive the new features. Please remember we expect to see some issues, and anything you come up with will save you when you'll install final release Remember to try daily tasks you'd usually do in the engine, to see there are no regressions. Write down the configuration you used (HW, console, etc) in the report etherpad[1]. Documentation Release notes: http://www.ovirt.org/OVirt_3.5_Release_Notes Features pages links: http://bit.ly/17qBn6F If you find errors in the wiki please annotate it as well in report etherpad [1] Prerequisites / recommendations Use CentOS or RHEL 6.5 only. 6.4 is unsupported due to various issues (sanlock, libvirt, etc). Use Fedora 19 or 20. Latest RPMs repository to be enabled for testing the release are listed in the release notes page [2]. NEW issues / reports For any new issue, please update the reports etherpad [1] Feature owners, please make sure: your feature is updated and referenced on release page [2]. you have testing instruction for your feature either on test day page [3] or in your feature page. your team regression testing section is organized and up to date on test day page [3]. [1] http://etherpad.ovirt.org/p/3.5-testday-3 [2] http://www.ovirt.org/OVirt_3.5_Release_Notes [3] http://www.ovirt.org/OVirt_3.5_TestDay Thanks. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Broken dependencies: vdsm
[Adding vdsm-devel/ovirt-devel] - Original Message - From: Kaleb S. KEITHLEY kkeit...@redhat.com To: Balamurugan Arumugam barum...@redhat.com, Dan Kenigsberg dan...@redhat.com Cc: Lalatendu Mohanty lmoha...@redhat.com, build...@fedoraproject.org, Development discussions related to Fedora de...@lists.fedoraproject.org, glusterfs-ow...@fedoraproject.org Sent: Monday, September 15, 2014 9:27:03 PM Subject: Re: Broken dependencies: vdsm Posting to -devel because I can't post to vdsm-owner or virt-maintenance. On 09/15/2014 10:09 AM, Kaleb S. KEITHLEY wrote: gluster server. AFAIK it's a mistake for vdsm to have these as dependencies. Correcting myself. glusterfs-cli is okay, and should, AFAIK, be in RHEL6, although I'm not seeing that it is. glusterfs-server is not in RHEL6, and won't ever be in RHEL6, and AFAIK it's a mistake for vdsm to have it as a dependency. Looks like to me too. Lets check with vdsm-devel/ovirt-devel? Regards, Bala ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
