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