----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com>, board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 3:21:26 PM Subject: Re: 3.5 Time-frame: pushing feature freeze
On 05/28/2014 06:01 PM, Doron Fediuck wrote:
Hi, The current date for feature freeze is May 30. Based on today's weekly sync[1], it seems that most teams require additional 2 weeks to conclude current work.
Therefore I suggest to set an updated FF milestone for June 15.
If you need more time or think we should not change the current date please respond.
I think we should prioritize schedule over capacity. Features which do not make it to FF can wait for the next release.
I think that we should be more careful in the planning phase because it seems to be a recurring phenomena where people commit for features they know won't make it to FF - still these features get approved for the release.
I suggest to adopt a spec review phase, which would become part of the planning phase, Here is the process (which is similar to some of the openstack projects' process):
1. For each feature the owner would have to submit a spec file which includes a description and details of the feature (like what feature pages should include today - and mostly do not!).
An example would be - https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs...
2. The specs are getting reviews and hopefully approved after they meet some standards and make sense to add to oVirt.
3. Once a spec is approved it can be a candidate to include in the release ( at this point the owner should have a good estimation on how long it is going to take him to implement the proposed spec)
4. The release manager of the version should approve the spec for the version according to the well known deadlines.
Livnat
Thanks, Doron
[1] http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-28-14.01.txt
Livnat, it seems that most other teams need the extra time based on yesterday's weekly sync, which included a network representative as well. So regardless of networking the rest of the version is not ready to freeze hence this is needed. As for your suggestion I'm all for a proper discussion as it seems that the timeline wasn't kept so far and this is the last slip we can allow without changing GA date. Doron