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. Thanks Mike [1] http://wiki.ovirt.org/wiki/Second_Release
Hi Mike, On 08/20/2012 02:02 PM, Mike Burns wrote:
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.
Beyond the release criteria, there's the main goal of the release - what is the major problem oVirt users have that we can fix for the next release, for example? I find it useful to have one big user-visible goal to federate people around the release and give us a nice headline feature. Of course it's possible to have some smaller features we would like to add, and bugs we would like to fix. But the big goal provides both a neat way of prioritising work and a finish line to measure against. Cheers, Dave. -- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62
On 08/20/2012 05:43 PM, Dave Neary wrote:
Hi Mike,
On 08/20/2012 02:02 PM, Mike Burns wrote:
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.
Beyond the release criteria, there's the main goal of the release - what is the major problem oVirt users have that we can fix for the next release, for example?
I find it useful to have one big user-visible goal to federate people around the release and give us a nice headline feature. Of course it's possible to have some smaller features we would like to add, and bugs we would like to fix. But the big goal provides both a neat way of prioritising work and a finish line to measure against.
Cheers, Dave.
my view - that would be great, but such goals should be suggested by someone also committing to delivering them per the planned schedule.
Hi, On 08/20/2012 11:14 PM, Itamar Heim wrote:
On 08/20/2012 05:43 PM, Dave Neary wrote:
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.
Beyond the release criteria, there's the main goal of the release - what is the major problem oVirt users have that we can fix for the next release, for example? <snip>
my view - that would be great, but such goals should be suggested by someone also committing to delivering them per the planned schedule.
I agree - it's one of the things which I've found tricky to understand re the release manager role - the project maintainer is the one who should, I think, be setting the scope of the release, and the release manager is merely ensuring that everyone is aware of where we are within that scope. Since 3.1 is my first oVirt release, perhaps someone could explain how the scope of the 3.1 release was decided after the 3.0 release, and how we fared against that original plan during the release cycle? Cheers, Dave. -- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62
On 08/21/2012 12:20 AM, Dave Neary wrote:
Hi,
On 08/20/2012 11:14 PM, Itamar Heim wrote:
On 08/20/2012 05:43 PM, Dave Neary wrote:
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.
Beyond the release criteria, there's the main goal of the release - what is the major problem oVirt users have that we can fix for the next release, for example? <snip>
my view - that would be great, but such goals should be suggested by someone also committing to delivering them per the planned schedule.
I agree - it's one of the things which I've found tricky to understand re the release manager role - the project maintainer is the one who should, I think, be setting the scope of the release, and the release manager is merely ensuring that everyone is aware of where we are within that scope.
Since 3.1 is my first oVirt release, perhaps someone could explain how the scope of the 3.1 release was decided after the 3.0 release, and how we fared against that original plan during the release cycle?
we didn't define a scope for 3.1. people suggested features during the version and we did some fine tuning in the end on timing since some seemed worth the extra time to close/stabilize them. in general, I think we should define the schedule for 3.2, then see which features people would suggest to try and make the timeframe. in general, I think it should be a 3-month version (we said we wanted to move to 6 months cycle after the first few versions. I think we should stay on 3 months especially since 3.1 took longer to get the final blockers out and until released).
Cheers, Dave.
On Tue, 2012-08-21 at 00:30 +0300, Itamar Heim wrote:
On 08/21/2012 12:20 AM, Dave Neary wrote:
Hi,
On 08/20/2012 11:14 PM, Itamar Heim wrote:
On 08/20/2012 05:43 PM, Dave Neary wrote:
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.
Beyond the release criteria, there's the main goal of the release - what is the major problem oVirt users have that we can fix for the next release, for example? <snip>
my view - that would be great, but such goals should be suggested by someone also committing to delivering them per the planned schedule.
I agree - it's one of the things which I've found tricky to understand re the release manager role - the project maintainer is the one who should, I think, be setting the scope of the release, and the release manager is merely ensuring that everyone is aware of where we are within that scope.
Since 3.1 is my first oVirt release, perhaps someone could explain how the scope of the 3.1 release was decided after the 3.0 release, and how we fared against that original plan during the release cycle?
we didn't define a scope for 3.1. people suggested features during the version and we did some fine tuning in the end on timing since some seemed worth the extra time to close/stabilize them.
in general, I think we should define the schedule for 3.2, then see which features people would suggest to try and make the timeframe.
in general, I think it should be a 3-month version (we said we wanted to move to 6 months cycle after the first few versions. I think we should stay on 3 months especially since 3.1 took longer to get the final blockers out and until released).
I think I agree on the shorter time-table for 3.2. I also think we should get a list of features and commit to it and track against it on the weekly call. The 3-month schedule would put us in mid-November to early-December which I think is reasonable. Mike
Cheers, Dave.
_______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
On 21/08/12 15:31, Mike Burns wrote:
On Tue, 2012-08-21 at 00:30 +0300, Itamar Heim wrote:
On 08/21/2012 12:20 AM, Dave Neary wrote:
Hi,
On 08/20/2012 11:14 PM, Itamar Heim wrote:
On 08/20/2012 05:43 PM, Dave Neary wrote:
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.
Beyond the release criteria, there's the main goal of the release - what is the major problem oVirt users have that we can fix for the next release, for example? <snip>
my view - that would be great, but such goals should be suggested by someone also committing to delivering them per the planned schedule.
I agree - it's one of the things which I've found tricky to understand re the release manager role - the project maintainer is the one who should, I think, be setting the scope of the release, and the release manager is merely ensuring that everyone is aware of where we are within that scope.
Since 3.1 is my first oVirt release, perhaps someone could explain how the scope of the 3.1 release was decided after the 3.0 release, and how we fared against that original plan during the release cycle?
we didn't define a scope for 3.1. people suggested features during the version and we did some fine tuning in the end on timing since some seemed worth the extra time to close/stabilize them.
in general, I think we should define the schedule for 3.2, then see which features people would suggest to try and make the timeframe.
in general, I think it should be a 3-month version (we said we wanted to move to 6 months cycle after the first few versions. I think we should stay on 3 months especially since 3.1 took longer to get the final blockers out and until released).
I think I agree on the shorter time-table for 3.2. I also think we should get a list of features and commit to it and track against it on the weekly call. The 3-month schedule would put us in mid-November to early-December which I think is reasonable.
Mike
I agree we should keep the short cycles, so many things changed and so many fixes were pushed, I see no reason to hold the next release for longer than 3 month + some blockers delay. I am not sure we must have new features in each release, a release of bug fixes seems also reasonable to me. Why not keep it only time-based release regardless of commitments for new features for the release. We can ask what new features are planned/expected to be pushed in the near future, if we get reply with a lot of features then we can call it major version (4.0) if we get only minor features we can use a minor version (3.2, 3.3, etc). Livnat
Cheers, Dave.
_______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
_______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
Hi, On 08/21/2012 03:01 PM, Livnat Peer wrote:
On 21/08/12 15:31, Mike Burns wrote:
On Tue, 2012-08-21 at 00:30 +0300, Itamar Heim wrote:
in general, I think it should be a 3-month version (we said we wanted to move to 6 months cycle after the first few versions. I think we should stay on 3 months especially since 3.1 took longer to get the final blockers out and until released).
I think I agree on the shorter time-table for 3.2. I also think we should get a list of features and commit to it and track against it on the weekly call. The 3-month schedule would put us in mid-November to early-December which I think is reasonable.
My only concern committing to a 3 month cycle for this release is that all we would have time for are bug fixes. Especially with work on RHEV 3.1 happening in parallel.
I agree we should keep the short cycles, so many things changed and so many fixes were pushed, I see no reason to hold the next release for longer than 3 month + some blockers delay.
How long was 3.1 in feature freeze? Are there newer features or developments that were done on a devel branch while it was in stabilisation? I'd prefer not to see us plan for delays! If they happen, so be it, but we should be able to identify most of the blockers early enough to avoid schedule skips, I hope.
I am not sure we must have new features in each release, a release of bug fixes seems also reasonable to me. Why not keep it only time-based release regardless of commitments for new features for the release.
I like giving people good reasons to upgrade, but also good reasons to install the current version - and in terms of communication, if we say that 3.2 will be "3.1, with lots of bug fixes", and that it will be along in 3 months, why would anyone install 3.1? We've just said it's a buggy release that will soon be obsoleted anyway. IMHO, it's better to say "here's what 3.1 does well, here's what 3.2 will be able to do that 3.1 doesn't". I'm not suggesting a revolution with every release, but one thing which is identifiable as "new in 3.2" doesn't seem like a lot to ask. That said, I have previously worked on a project, where we had one full release cycle whose goal was "make it work better on Linux", and it was a very positive release cycle, lots of new contributors and energy, because it was a goal people cared about. So purely bug-fix & stabilisation releases can work, if you have a measurable goal to compare against.
We can ask what new features are planned/expected to be pushed in the near future, if we get reply with a lot of features then we can call it major version (4.0) if we get only minor features we can use a minor version (3.2, 3.3, etc).
I don't care about major/minor versions - I have been in far too many discussions in both GNOME and GIMP on whether a release is "worth" a new major version. Personally, I have a view which is much like that of Queen Victoria towards bathing: I'm happy with incrementing the major version every year or two, whether it's needed or not. Cheers, Dave. -- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62
* Dave Neary <dneary@redhat.com> [2012-08-21 08:42]:
I am not sure we must have new features in each release, a release of bug fixes seems also reasonable to me. Why not keep it only time-based release regardless of commitments for new features for the release.
I like giving people good reasons to upgrade, but also good reasons to install the current version - and in terms of communication, if we say that 3.2 will be "3.1, with lots of bug fixes", and that it will be along in 3 months, why would anyone install 3.1? We've just said it's a buggy release that will soon be obsoleted anyway.
IMHO, it's better to say "here's what 3.1 does well, here's what 3.2 will be able to do that 3.1 doesn't". I'm not suggesting a revolution with every release, but one thing which is identifiable as "new in 3.2" doesn't seem like a lot to ask.
Definitely agree with this approach. We always want something new for the next release. It's probably worth keeping a list of features from each of the sub-projects as a potential next-release feature list. And with a defined release cycle, we can see which features will make the cut prior to a feature-freeze date. IMHO, one of our challenges is actually enumerating all of the potential features. I think there are lots of features under development, but I don't think we're collecting all of that info in a single place where you can get a view of potential features in the various sub-projects.
That said, I have previously worked on a project, where we had one full release cycle whose goal was "make it work better on Linux", and it was a very positive release cycle, lots of new contributors and energy, because it was a goal people cared about. So purely bug-fix & stabilisation releases can work, if you have a measurable goal to compare against.
We can ask what new features are planned/expected to be pushed in the near future, if we get reply with a lot of features then we can call it major version (4.0) if we get only minor features we can use a minor version (3.2, 3.3, etc).
I don't care about major/minor versions - I have been in far too many discussions in both GNOME and GIMP on whether a release is "worth" a new major version. Personally, I have a view which is much like that of Queen Victoria towards bathing: I'm happy with incrementing the major version every year or two, whether it's needed or not.
+1
Cheers, Dave.
-- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62 _______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
-- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com
On 21/08/12 17:01, Ryan Harper wrote:
* Dave Neary <dneary@redhat.com> [2012-08-21 08:42]:
I am not sure we must have new features in each release, a release of bug fixes seems also reasonable to me. Why not keep it only time-based release regardless of commitments for new features for the release.
I like giving people good reasons to upgrade, but also good reasons to install the current version - and in terms of communication, if we say that 3.2 will be "3.1, with lots of bug fixes", and that it will be along in 3 months, why would anyone install 3.1? We've just said it's a buggy release that will soon be obsoleted anyway.
IMHO, it's better to say "here's what 3.1 does well, here's what 3.2 will be able to do that 3.1 doesn't". I'm not suggesting a revolution with every release, but one thing which is identifiable as "new in 3.2" doesn't seem like a lot to ask.
Definitely agree with this approach. We always want something new for the next release.
I agree we want something new, the question is what is the release criteria. If I understand the above suggestion correctly If there are not enough new features we won't release in 3 months? I think this is a mistake because there are hundreds of bug fixes pushed into the repository and releasing a more stable version IMO has great value. For example in Networking we fixed one feature and will probably add one small feature by November, but I know that networking in 3.1 release is very buggy while if you take latest from upstream it is dramatically better, regardless of the features there is a value for releasing in November.
It's probably worth keeping a list of features from each of the sub-projects as a potential next-release feature list. And with a defined release cycle, we can see which features will make the cut prior to a feature-freeze date.
IMHO, one of our challenges is actually enumerating all of the potential features. I think there are lots of features under development, but I don't think we're collecting all of that info in a single place where you can get a view of potential features in the various sub-projects.
That said, I have previously worked on a project, where we had one full release cycle whose goal was "make it work better on Linux", and it was a very positive release cycle, lots of new contributors and energy, because it was a goal people cared about. So purely bug-fix & stabilisation releases can work, if you have a measurable goal to compare against.
We can ask what new features are planned/expected to be pushed in the near future, if we get reply with a lot of features then we can call it major version (4.0) if we get only minor features we can use a minor version (3.2, 3.3, etc).
I don't care about major/minor versions - I have been in far too many discussions in both GNOME and GIMP on whether a release is "worth" a new major version. Personally, I have a view which is much like that of Queen Victoria towards bathing: I'm happy with incrementing the major version every year or two, whether it's needed or not.
+1
Cheers, Dave.
-- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62 _______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
* Livnat Peer <lpeer@redhat.com> [2012-08-21 13:23]:
On 21/08/12 17:01, Ryan Harper wrote:
* Dave Neary <dneary@redhat.com> [2012-08-21 08:42]:
I am not sure we must have new features in each release, a release of bug fixes seems also reasonable to me. Why not keep it only time-based release regardless of commitments for new features for the release.
I like giving people good reasons to upgrade, but also good reasons to install the current version - and in terms of communication, if we say that 3.2 will be "3.1, with lots of bug fixes", and that it will be along in 3 months, why would anyone install 3.1? We've just said it's a buggy release that will soon be obsoleted anyway.
IMHO, it's better to say "here's what 3.1 does well, here's what 3.2 will be able to do that 3.1 doesn't". I'm not suggesting a revolution with every release, but one thing which is identifiable as "new in 3.2" doesn't seem like a lot to ask.
Definitely agree with this approach. We always want something new for the next release.
I agree we want something new, the question is what is the release criteria. If I understand the above suggestion correctly If there are not enough new features we won't release in 3 months? I think this is a mistake because there are hundreds of bug fixes pushed into the repository and releasing a more stable version IMO has great value.
This is what a stable release stream is for. QEMU maintains a stable release until the next version is available. We could produce a 3.1.1 release and keep that going until 3.2 comes out. And if we don't have new features in 3 months, then it's probably too short of a release cycle. The last thing we want to do is introduce *more* churn into engine deployments. If we have a stable release, this would make a longer cycle, like 6 months, more reasonable.
For example in Networking we fixed one feature and will probably add one small feature by November, but I know that networking in 3.1 release is very buggy while if you take latest from upstream it is dramatically better, regardless of the features there is a value for releasing in November.
definitely material for a stable release. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com
On 21/08/12 22:00, Ryan Harper wrote:
* Livnat Peer <lpeer@redhat.com> [2012-08-21 13:23]:
On 21/08/12 17:01, Ryan Harper wrote:
* Dave Neary <dneary@redhat.com> [2012-08-21 08:42]:
I am not sure we must have new features in each release, a release of bug fixes seems also reasonable to me. Why not keep it only time-based release regardless of commitments for new features for the release.
I like giving people good reasons to upgrade, but also good reasons to install the current version - and in terms of communication, if we say that 3.2 will be "3.1, with lots of bug fixes", and that it will be along in 3 months, why would anyone install 3.1? We've just said it's a buggy release that will soon be obsoleted anyway.
IMHO, it's better to say "here's what 3.1 does well, here's what 3.2 will be able to do that 3.1 doesn't". I'm not suggesting a revolution with every release, but one thing which is identifiable as "new in 3.2" doesn't seem like a lot to ask.
Definitely agree with this approach. We always want something new for the next release.
I agree we want something new, the question is what is the release criteria. If I understand the above suggestion correctly If there are not enough new features we won't release in 3 months? I think this is a mistake because there are hundreds of bug fixes pushed into the repository and releasing a more stable version IMO has great value.
This is what a stable release stream is for. QEMU maintains a stable release until the next version is available. We could produce a 3.1.1 release and keep that going until 3.2 comes out.
And if we don't have new features in 3 months, then it's probably too short of a release cycle. The last thing we want to do is introduce *more* churn into engine deployments. If we have a stable release, this would make a longer cycle, like 6 months, more reasonable.
I'm perfectly fine with releasing in November a 3.1.1 as a stable release. As long as we don't postpone releasing 'something' further than November. The only issue that comes to mind when we start discussing z-stream is the churn we'll have (as developers): - We'll need to cherry pick instead of rebasing, which means sending patches twice, testing it twice, rewriting parts if needed etc. It would have been ok if we didn't have to cherry pick a few dozens patches in networking alone. - We'll need to take care of upgrades more carefully, which always makes our work more interesting but also more complicated (do we require upgrading to 3.1.z before upgrading to 3.2? testing the upgrade process etc.) I think that going forward we'll do better if we can create the next z-stream branch as soon as we release so we can cherry pick as we go, now we have a gap of about 8 weeks (? - not sure actually) since last rebase, that's a lot of work. I suggest that the release in November will still be 3.2 and hopefully we can get enough features to make it attractive, and then we'll create the z-stream branch, so we can release 3.2.z as needed (instead of doing 3.3 with not enough meaningful content).
For example in Networking we fixed one feature and will probably add one small feature by November, but I know that networking in 3.1 release is very buggy while if you take latest from upstream it is dramatically better, regardless of the features there is a value for releasing in November.
definitely material for a stable release.
Hi, On 08/22/2012 08:19 AM, Livnat Peer wrote:
I'm perfectly fine with releasing in November a 3.1.1 as a stable release. As long as we don't postpone releasing 'something' further than November.
I'd be happy to release a 3.1.1 release as soon as we have a fix for the NFS issue affecting 3.1 VDSM & Node builds.
The only issue that comes to mind when we start discussing z-stream is the churn we'll have (as developers):
- We'll need to cherry pick instead of rebasing, which means sending patches twice, testing it twice, rewriting parts if needed etc. It would have been ok if we didn't have to cherry pick a few dozens patches in networking alone.
- We'll need to take care of upgrades more carefully, which always makes our work more interesting but also more complicated (do we require upgrading to 3.1.z before upgrading to 3.2? testing the upgrade process etc.)
I think that going forward we'll do better if we can create the next z-stream branch as soon as we release so we can cherry pick as we go, now we have a gap of about 8 weeks (? - not sure actually) since last rebase, that's a lot of work.
I suggest that the release in November will still be 3.2 and hopefully we can get enough features to make it attractive, and then we'll create the z-stream branch, so we can release 3.2.z as needed (instead of doing 3.3 with not enough meaningful content).
It might help focus the conversation if we could have a list of features which have been started (or even finished) in the devel branch? I'd love to know what the general branching strategy for oVirt has been. Thanks! Dave. -- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62
On 22/08/12 11:24, Dave Neary wrote:
Hi,
On 08/22/2012 08:19 AM, Livnat Peer wrote:
I'm perfectly fine with releasing in November a 3.1.1 as a stable release. As long as we don't postpone releasing 'something' further than November.
I'd be happy to release a 3.1.1 release as soon as we have a fix for the NFS issue affecting 3.1 VDSM & Node builds.
The only issue that comes to mind when we start discussing z-stream is the churn we'll have (as developers):
- We'll need to cherry pick instead of rebasing, which means sending patches twice, testing it twice, rewriting parts if needed etc. It would have been ok if we didn't have to cherry pick a few dozens patches in networking alone.
- We'll need to take care of upgrades more carefully, which always makes our work more interesting but also more complicated (do we require upgrading to 3.1.z before upgrading to 3.2? testing the upgrade process etc.)
I think that going forward we'll do better if we can create the next z-stream branch as soon as we release so we can cherry pick as we go, now we have a gap of about 8 weeks (? - not sure actually) since last rebase, that's a lot of work.
I suggest that the release in November will still be 3.2 and hopefully we can get enough features to make it attractive, and then we'll create the z-stream branch, so we can release 3.2.z as needed (instead of doing 3.3 with not enough meaningful content).
It might help focus the conversation if we could have a list of features which have been started (or even finished) in the devel branch? I'd love to know what the general branching strategy for oVirt has been.
For networking - - We pushed bridge-less networks (which was suppose to be in 3.1 but did not make it) - We are working right now on MAC anti-spoofing per VM - this should be ready in the next month or so. About other features - - In storage i think we pushed grayed out LUNs, and I know there are discussions+work upstream on live storage migration, not sure if it would make it by November. - There are some discussions and WIP patches on UI plugins but again not sure if it would be ready by November. - There is work around host bootstrap (some of it already pushed upstream) - Gluster guys are working on import cluster - not sure what the status is. I am sure there are other features we can ask on the dev lists (engine and vdsm) and see what else is out there. Generally for each feature we should have a feature page and we can ask the feature owner what is the target release of this feature. About branching policy I'm not sure if we have one, except for creating a branch before release for stabilization. Thanks, Livnat
Thanks! Dave.
Hi, On 08/22/2012 11:02 AM, Livnat Peer wrote:
About branching policy I'm not sure if we have one, except for creating a branch before release for stabilization.
Allow me to rephrase & make this concrete: In the GNOME project, modules branch as close as possible to release - usually on the release day, or when making a release candidate. In effect, the developers agree to work on new features only on branches, and the trunk is where most of the pre-release work gets done. Branches get merged back into the trunk when they're ready, and not before - and never when we're in feature freeze. We branch a stable branch for fixes to bugs in the stable release, and those are as a matter of course fixed in trunk first, and back-ported to the stable branch. We have time-based stable releases of the stable branch during the first 6 weeks of a release cycle to get those fixes out to distros & users. My understanding of what you've said so far is that at some point (long before the August 8th release date), a 3.1 release branch was made, and only bug fixes to features which had been included in 3.1 were added to that branch from that date. In the meantime, feature and bug fixing work continued also on the stable branch, but not all of those bug fixes were back-ported to the pre-release branch. I'm guessing that branch was made when we hit 3.1 feature freeze? If my understanding is correct, you then have a period of several months (because of the release date slip) when the 3.1 branch is not moving very much, and everyone is working on the trunk branch, including developing new features. The end result is that when the release is made, there is already a big diff with trunk, and as you point out, cherry-picking bug fixes for inclusion on a 3.1 branch is a lot of work. In my mind, the work on 3.2 started when we made the 3.1 branch, in this scenario, so perhaps we're already too late to discuss what needs to be included in the 3.2 release - perhaps we should simply work on finishing/stabilising what we have now for release? Again, excuse me if I'm over-stepping bounds, I'm just trying to figure out where the work in the project is getting done, and what that implies for this thread. Cheers, Dave. -- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62
On Wed, 2012-08-22 at 15:56 +0200, Dave Neary wrote:
Hi,
On 08/22/2012 11:02 AM, Livnat Peer wrote:
About branching policy I'm not sure if we have one, except for creating a branch before release for stabilization.
Allow me to rephrase & make this concrete:
In the GNOME project, modules branch as close as possible to release - usually on the release day, or when making a release candidate. In effect, the developers agree to work on new features only on branches, and the trunk is where most of the pre-release work gets done. Branches get merged back into the trunk when they're ready, and not before - and never when we're in feature freeze.
We branch a stable branch for fixes to bugs in the stable release, and those are as a matter of course fixed in trunk first, and back-ported to the stable branch. We have time-based stable releases of the stable branch during the first 6 weeks of a release cycle to get those fixes out to distros & users.
My understanding of what you've said so far is that at some point (long before the August 8th release date), a 3.1 release branch was made, and only bug fixes to features which had been included in 3.1 were added to that branch from that date. In the meantime, feature and bug fixing work continued also on the stable branch, but not all of those bug fixes were back-ported to the pre-release branch. I'm guessing that branch was made when we hit 3.1 feature freeze?
If my understanding is correct, you then have a period of several months (because of the release date slip) when the 3.1 branch is not moving very much, and everyone is working on the trunk branch, including developing new features. The end result is that when the release is made, there is already a big diff with trunk, and as you point out, cherry-picking bug fixes for inclusion on a 3.1 branch is a lot of work.
In my mind, the work on 3.2 started when we made the 3.1 branch, in this scenario, so perhaps we're already too late to discuss what needs to be included in the 3.2 release - perhaps we should simply work on finishing/stabilising what we have now for release?
Again, excuse me if I'm over-stepping bounds, I'm just trying to figure out where the work in the project is getting done, and what that implies for this thread.
According to our release process [1], we stop feature development about 1-2 months (depending on the time frame of the release). At that time, we should have version branches created which take only stabilization and bug fix patches. Development for future releases continues during that time frame on master branches of new features. [1] http://wiki.ovirt.org/wiki/Release_Process
Cheers, Dave.
On 22/08/12 16:56, Dave Neary wrote:
Hi,
On 08/22/2012 11:02 AM, Livnat Peer wrote:
About branching policy I'm not sure if we have one, except for creating a branch before release for stabilization.
Allow me to rephrase & make this concrete:
In the GNOME project, modules branch as close as possible to release - usually on the release day, or when making a release candidate. In effect, the developers agree to work on new features only on branches, and the trunk is where most of the pre-release work gets done. Branches get merged back into the trunk when they're ready, and not before - and never when we're in feature freeze.
We branch a stable branch for fixes to bugs in the stable release, and those are as a matter of course fixed in trunk first, and back-ported to the stable branch. We have time-based stable releases of the stable branch during the first 6 weeks of a release cycle to get those fixes out to distros & users.
My understanding of what you've said so far is that at some point (long before the August 8th release date), a 3.1 release branch was made, and only bug fixes to features which had been included in 3.1 were added to that branch from that date. In the meantime, feature and bug fixing work continued also on the stable branch, but not all of those bug fixes were back-ported to the pre-release branch. I'm guessing that branch was made when we hit 3.1 feature freeze?
If my understanding is correct, you then have a period of several months (because of the release date slip) when the 3.1 branch is not moving very much, and everyone is working on the trunk branch, including developing new features. The end result is that when the release is made, there is already a big diff with trunk, and as you point out, cherry-picking bug fixes for inclusion on a 3.1 branch is a lot of work.
In my mind, the work on 3.2 started when we made the 3.1 branch, in this scenario, so perhaps we're already too late to discuss what needs to be included in the 3.2 release - perhaps we should simply work on finishing/stabilising what we have now for release?
+1, I suggest that instead of stabilizing what we have now, we'll send a release date and a feature freeze (FF) date to the dev lists, and see if there are any comments about the plan, maybe postponing FF by a week or so can give us more features etc. On the agreed FF date we'll create the 3.2 branch and ask all stabilization patches to be cherry picked to the 3.2 branch. I think we should discuss now what should happen with the next-next release :) after releasing 3.2 we'll have the same dilemma we are having today. How will we make the decision if the following release is 3.3 or 3.2.1, do we want to create 3.2.1 on our 3.2 release date and ask for all stabilization patches to be back ported there? and if we see that we want to release 3.3 at the end and no need for 3.2.1 will all the cherry picking be for vane?
Again, excuse me if I'm over-stepping bounds, I'm just trying to figure out where the work in the project is getting done, and what that implies for this thread.
I think it is a useful discussion and can help us going forward. There is a great value in your participation and in any experience someone brings to the table.
Cheers, Dave.
On 08/23/2012 09:05 AM, Livnat Peer wrote:
On 22/08/12 16:56, Dave Neary wrote:
Hi,
On 08/22/2012 11:02 AM, Livnat Peer wrote:
About branching policy I'm not sure if we have one, except for creating a branch before release for stabilization.
Allow me to rephrase & make this concrete:
In the GNOME project, modules branch as close as possible to release - usually on the release day, or when making a release candidate. In effect, the developers agree to work on new features only on branches, and the trunk is where most of the pre-release work gets done. Branches get merged back into the trunk when they're ready, and not before - and never when we're in feature freeze.
We branch a stable branch for fixes to bugs in the stable release, and those are as a matter of course fixed in trunk first, and back-ported to the stable branch. We have time-based stable releases of the stable branch during the first 6 weeks of a release cycle to get those fixes out to distros & users.
My understanding of what you've said so far is that at some point (long before the August 8th release date), a 3.1 release branch was made, and only bug fixes to features which had been included in 3.1 were added to that branch from that date. In the meantime, feature and bug fixing work continued also on the stable branch, but not all of those bug fixes were back-ported to the pre-release branch. I'm guessing that branch was made when we hit 3.1 feature freeze?
If my understanding is correct, you then have a period of several months (because of the release date slip) when the 3.1 branch is not moving very much, and everyone is working on the trunk branch, including developing new features. The end result is that when the release is made, there is already a big diff with trunk, and as you point out, cherry-picking bug fixes for inclusion on a 3.1 branch is a lot of work.
In my mind, the work on 3.2 started when we made the 3.1 branch, in this scenario, so perhaps we're already too late to discuss what needs to be included in the 3.2 release - perhaps we should simply work on finishing/stabilising what we have now for release?
+1, I suggest that instead of stabilizing what we have now, we'll send a release date and a feature freeze (FF) date to the dev lists, and see if there are any comments about the plan, maybe postponing FF by a week or so can give us more features etc. On the agreed FF date we'll create the 3.2 branch and ask all stabilization patches to be cherry picked to the 3.2 branch.
I think we should discuss now what should happen with the next-next release :) after releasing 3.2 we'll have the same dilemma we are having today. How will we make the decision if the following release is 3.3 or 3.2.1, do we want to create 3.2.1 on our 3.2 release date and ask for all stabilization patches to be back ported there? and if we see that we want to release 3.3 at the end and no need for 3.2.1 will all the cherry picking be for vane?
I think based on amount of changes / their scope / suggested/requested cycle for the release. another option we can consider is to allow working on both long term major release in parallel with short term release. i.e., have both 3.2 and 4.0 compatibly levels in master, so code can be written for both. not sure other projects do something similar though - usually master is a single head going forward.
Again, excuse me if I'm over-stepping bounds, I'm just trying to figure out where the work in the project is getting done, and what that implies for this thread.
I think it is a useful discussion and can help us going forward. There is a great value in your participation and in any experience someone brings to the table.
Cheers, Dave.
_______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
On 08/23/2012 09:05 AM, Livnat Peer wrote:
On 22/08/12 16:56, Dave Neary wrote:
Hi,
On 08/22/2012 11:02 AM, Livnat Peer wrote:
About branching policy I'm not sure if we have one, except for creating a branch before release for stabilization. Allow me to rephrase & make this concrete:
In the GNOME project, modules branch as close as possible to release - usually on the release day, or when making a release candidate. In effect, the developers agree to work on new features only on branches, and the trunk is where most of the pre-release work gets done. Branches get merged back into the trunk when they're ready, and not before - and never when we're in feature freeze.
We branch a stable branch for fixes to bugs in the stable release, and those are as a matter of course fixed in trunk first, and back-ported to the stable branch. We have time-based stable releases of the stable branch during the first 6 weeks of a release cycle to get those fixes out to distros & users.
My understanding of what you've said so far is that at some point (long before the August 8th release date), a 3.1 release branch was made, and only bug fixes to features which had been included in 3.1 were added to that branch from that date. In the meantime, feature and bug fixing work continued also on the stable branch, but not all of those bug fixes were back-ported to the pre-release branch. I'm guessing that branch was made when we hit 3.1 feature freeze?
If my understanding is correct, you then have a period of several months (because of the release date slip) when the 3.1 branch is not moving very much, and everyone is working on the trunk branch, including developing new features. The end result is that when the release is made, there is already a big diff with trunk, and as you point out, cherry-picking bug fixes for inclusion on a 3.1 branch is a lot of work.
In my mind, the work on 3.2 started when we made the 3.1 branch, in this scenario, so perhaps we're already too late to discuss what needs to be included in the 3.2 release - perhaps we should simply work on finishing/stabilising what we have now for release?
+1, I suggest that instead of stabilizing what we have now, we'll send a release date and a feature freeze (FF) date to the dev lists, and see if there are any comments about the plan, maybe postponing FF by a week or so can give us more features etc. On the agreed FF date we'll create the 3.2 branch and ask all stabilization patches to be cherry picked to the 3.2 branch.
I may be a bit biased because I'm from QE, but I do suggest a different path - remain stable at all times. The huge delay in releasing 3.1 due to quality issues supports this. It means development may be a bit slower, but it'll pay off in release time and quality. Y.
I think we should discuss now what should happen with the next-next release :) after releasing 3.2 we'll have the same dilemma we are having today. How will we make the decision if the following release is 3.3 or 3.2.1, do we want to create 3.2.1 on our 3.2 release date and ask for all stabilization patches to be back ported there? and if we see that we want to release 3.3 at the end and no need for 3.2.1 will all the cherry picking be for vane?
Again, excuse me if I'm over-stepping bounds, I'm just trying to figure out where the work in the project is getting done, and what that implies for this thread. I think it is a useful discussion and can help us going forward. There is a great value in your participation and in any experience someone brings to the table.
Cheers, Dave.
_______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
Hi, On 08/23/2012 10:59 AM, Yaniv Kaul wrote:
On 08/23/2012 09:05 AM, Livnat Peer wrote:
+1, I suggest that instead of stabilizing what we have now, we'll send a release date and a feature freeze (FF) date to the dev lists, and see if there are any comments about the plan, maybe postponing FF by a week or so can give us more features etc. On the agreed FF date we'll create the 3.2 branch and ask all stabilization patches to be cherry picked to the 3.2 branch.
I may be a bit biased because I'm from QE, but I do suggest a different path - remain stable at all times. The huge delay in releasing 3.1 due to quality issues supports this. It means development may be a bit slower, but it'll pay off in release time and quality.
The major issue I see with the current way of doing things is that it makes it harder for developers to test their work. You have 2 active branches where work is getting done almost all the time, with the result that you need to keep 2 complete environments around to test both versions, it takes extra effort to be conscientious and back-port fixes from the devel branch to the pre-release branch, etc. I suggested on IRC that features be developed entirely on branches until they're done and tested. That adds overhead to the developers too, and new features will still need some integration work when merged. But this would definitely get us closer to Yaniv's goal of an always-releasable branch. When it comes down to it, I think it's useful to have everyone working in the same place for as long as possible - I much prefer having everyone working towards getting a release out the door, or everyone working on new features, rather than having people split their attention between both, and as a result neither gets done as well as they could be. Cheers, Dave. -- Dave Neary Community Action and Impact Open Source and Standards, Red Hat Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
* Dave Neary <dneary@redhat.com> [2012-08-23 04:11]:
Hi,
On 08/23/2012 10:59 AM, Yaniv Kaul wrote:
On 08/23/2012 09:05 AM, Livnat Peer wrote:
+1, I suggest that instead of stabilizing what we have now, we'll send a release date and a feature freeze (FF) date to the dev lists, and see if there are any comments about the plan, maybe postponing FF by a week or so can give us more features etc. On the agreed FF date we'll create the 3.2 branch and ask all stabilization patches to be cherry picked to the 3.2 branch.
I may be a bit biased because I'm from QE, but I do suggest a different path - remain stable at all times. The huge delay in releasing 3.1 due to quality issues supports this. It means development may be a bit slower, but it'll pay off in release time and quality.
The major issue I see with the current way of doing things is that it makes it harder for developers to test their work. You have 2 active branches where work is getting done almost all the time, with the result that you need to keep 2 complete environments around to test both versions, it takes extra effort to be conscientious and back-port fixes from the devel branch to the pre-release branch, etc.
I suggested on IRC that features be developed entirely on branches until they're done and tested. That adds overhead to the developers too, and new features will still need some integration work when merged. But this would definitely get us closer to Yaniv's goal of an always-releasable branch.
I very much like the idea of working a feature out-of-mainline tree. In QEMU (and other git projects) a new feature is developed separately, and the maintainer of the feature pulls in changes/fixes and rebases as needed before submitting (or requesting a pull from the maintainer). Only features that are ready (passed some testing, review, etc) are merged into the tree. With gerrit in place, this still can happen, it just happens within the main repository under branches. It appears more difficult to me to use the same git repo than separate where it's easy to point to a seperate repo where the feature is being developed to test/review etc. But, that's an implementation detail for the developers.
When it comes down to it, I think it's useful to have everyone working in the same place for as long as possible - I much prefer having everyone working towards getting a release out the door, or everyone working on new features, rather than having people split their attention between both, and as a result neither gets done as well as they could be.
Yes, I think it's much easier to focus the whole teams effort around the current release/branch and getting it ready for the next release.
Cheers, Dave.
-- Dave Neary Community Action and Impact Open Source and Standards, Red Hat Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
_______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
-- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com
* Livnat Peer <lpeer@redhat.com> [2012-08-22 01:22]:
On 21/08/12 22:00, Ryan Harper wrote:
* Livnat Peer <lpeer@redhat.com> [2012-08-21 13:23]:
On 21/08/12 17:01, Ryan Harper wrote:
* Dave Neary <dneary@redhat.com> [2012-08-21 08:42]:
I am not sure we must have new features in each release, a release of bug fixes seems also reasonable to me. Why not keep it only time-based release regardless of commitments for new features for the release.
I like giving people good reasons to upgrade, but also good reasons to install the current version - and in terms of communication, if we say that 3.2 will be "3.1, with lots of bug fixes", and that it will be along in 3 months, why would anyone install 3.1? We've just said it's a buggy release that will soon be obsoleted anyway.
IMHO, it's better to say "here's what 3.1 does well, here's what 3.2 will be able to do that 3.1 doesn't". I'm not suggesting a revolution with every release, but one thing which is identifiable as "new in 3.2" doesn't seem like a lot to ask.
Definitely agree with this approach. We always want something new for the next release.
I agree we want something new, the question is what is the release criteria. If I understand the above suggestion correctly If there are not enough new features we won't release in 3 months? I think this is a mistake because there are hundreds of bug fixes pushed into the repository and releasing a more stable version IMO has great value.
This is what a stable release stream is for. QEMU maintains a stable release until the next version is available. We could produce a 3.1.1 release and keep that going until 3.2 comes out.
And if we don't have new features in 3 months, then it's probably too short of a release cycle. The last thing we want to do is introduce *more* churn into engine deployments. If we have a stable release, this would make a longer cycle, like 6 months, more reasonable.
I'm perfectly fine with releasing in November a 3.1.1 as a stable release. As long as we don't postpone releasing 'something' further than November.
Certainly, we're still discussing what a stable branch/release for oVirt means; I don't think this discussion should hold up reasonable plans.
The only issue that comes to mind when we start discussing z-stream is the churn we'll have (as developers):
- We'll need to cherry pick instead of rebasing, which means sending patches twice, testing it twice, rewriting parts if needed etc. It would have been ok if we didn't have to cherry pick a few dozens patches in networking alone.
- We'll need to take care of upgrades more carefully, which always makes our work more interesting but also more complicated (do we require upgrading to 3.1.z before upgrading to 3.2? testing the upgrade process etc.)
This may be part of our stable patch requirements. It should be bug fixes only and shouldn't introduce anything that would require updating before upgrading; though one can imagine a case where upgrading fails without one of the stable fixes.
I think that going forward we'll do better if we can create the next z-stream branch as soon as we release so we can cherry pick as we go, now we have a gap of about 8 weeks (? - not sure actually) since last rebase, that's a lot of work.
Yeah, normally the stable branch is opened as soon as the release goes out, and patches that affect the current release are pushed into the stable branch.
I suggest that the release in November will still be 3.2 and hopefully we can get enough features to make it attractive, and then we'll create the z-stream branch, so we can release 3.2.z as needed (instead of doing 3.3 with not enough meaningful content).
-- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Dave Neary" <dneary@redhat.com> Cc: board@ovirt.org Sent: Monday, August 20, 2012 5:30:54 PM Subject: Re: Next Release Planning
On 08/21/2012 12:20 AM, Dave Neary wrote:
Hi,
On 08/20/2012 11:14 PM, Itamar Heim wrote:
On 08/20/2012 05:43 PM, Dave Neary wrote:
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.
Beyond the release criteria, there's the main goal of the release - what is the major problem oVirt users have that we can fix for the next release, for example? <snip>
my view - that would be great, but such goals should be suggested by someone also committing to delivering them per the planned schedule.
I agree - it's one of the things which I've found tricky to understand re the release manager role - the project maintainer is the one who should, I think, be setting the scope of the release, and the release manager is merely ensuring that everyone is aware of where we are within that scope.
Since 3.1 is my first oVirt release, perhaps someone could explain how the scope of the 3.1 release was decided after the 3.0 release, and how we fared against that original plan during the release cycle?
we didn't define a scope for 3.1.
One of the problems with this was that right up to release it was very hard even for people involved in the project to nail down exactly what actually did make it in. Imagine then how difficult it must be for people who just want to use it or decide which version to install/upgrade to work out. You were kind enough to give me a list for the release notes in lieu of the list of feature bugs that I asked for (apparently we don't have feature 'bugs' for oVirt?), but even that had many items with question marks on them. We had feature pages, but I don't recall many (any?) saying whether the feature was complete or not. Proper scoping of the release and a defined process for getting features into it - and tracking their progress - would help here. It's not just about release notes, it's about ensuring consistent messaging for everyone - users and contributors alike. Steve
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Aeolus Community Manager http://www.aeolusproject.org
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. Mike
Regards and best wishes,
Justin Clift
Thanks
Mike
[1] http://wiki.ovirt.org/wiki/Second_Release
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Aeolus Community Manager http://www.aeolusproject.org
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
* Mike Burns <mburns@redhat.com> [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.
From there, building/writing some tests using either engine-cli, or
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. 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Aeolus Community Manager http://www.aeolusproject.org
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
-- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com
On Tue, 2012-08-21 at 09:10 -0500, Ryan Harper wrote:
* Mike Burns <mburns@redhat.com> [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?
Just want to point out that ^^ wouldn't catch that ovirt-node is un-usable due to a kernel/vdsm bug. allinone testing is a good idea to catch many issues, but we need to be running some sort of end-to-end testing with ovirt-node as well. Mike
Mike
Regards and best wishes,
Justin Clift
Thanks
Mike
[1] http://wiki.ovirt.org/wiki/Second_Release
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Aeolus Community Manager http://www.aeolusproject.org
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
* Mike Burns <mburns@redhat.com> [2012-08-21 09:25]:
On Tue, 2012-08-21 at 09:10 -0500, Ryan Harper wrote:
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?
Just want to point out that ^^ wouldn't catch that ovirt-node is un-usable due to a kernel/vdsm bug. allinone testing is a good idea to catch many issues, but we need to be running some sort of end-to-end testing with ovirt-node as well.
Booting the image is the starting point. One of the tests to run on-top of an all-in-one would be attempting adding an NFS export domain from localhost. And the list goes on. Depending on the complexity of the tests, it may not lend itself to a jenkins job, but I think approach of writing engine level FVT and running it against the all-in-one is sound. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com
participants (8)
-
Dave Neary -
Itamar Heim -
Justin Clift -
Livnat Peer -
Mike Burns -
Ryan Harper -
Steve Gordon -
Yaniv Kaul