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.

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?

my view - that would be great, but such goals should be suggested by someone also committing to delivering them per the planned schedule.

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. > _______________________________________________ Board mailing list Board(a)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: >> 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.

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).

* Dave Neary <dneary(a)redhat.com&gt; [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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/board

* Livnat Peer <lpeer(a)redhat.com&gt; [2012-08-21 13:23]: > On 21/08/12 17:01, Ryan Harper wrote: >> * Dave Neary <dneary(a)redhat.com&gt; [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.

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.

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.

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. > _______________________________________________ Board mailing list Board(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/board

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.

On 21/08/12 22:00, Ryan Harper wrote: > * Livnat Peer <lpeer(a)redhat.com&gt; [2012-08-21 13:23]: >> On 21/08/12 17:01, Ryan Harper wrote: >>> * Dave Neary <dneary(a)redhat.com&gt; [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).

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 _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

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

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

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.