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 >> [email protected] >> http://lists.ovirt.org/mailman/listinfo/board > > > _______________________________________________ > Board mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/board > _______________________________________________ Board mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/board
