Re: 3.5 Time-frame: pushing feature freeze

From: "Livnat Peer" <lpeer(a)redhat.com&gt; To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; Cc: board(a)ovirt.org, devel(a)ovirt.org Sent: Thursday, May 29, 2014 4:05:45 PM Subject: Re: 3.5 Time-frame: pushing feature freeze On 05/29/2014 03:44 PM, Doron Fediuck wrote: > > > ----- Original Message ----- >> From: "Livnat Peer" <lpeer(a)redhat.com&gt; >> To: "Doron Fediuck" <dfediuck(a)redhat.com&gt;, board(a)ovirt.org, >> devel(a)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-sp... >> >> 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. > This is not about a specific team status, this is more about our general approach to deadlines which should be less flexible.

> 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. > I wonder how can we postpone FF by 6 weeks from the original date without any impact on the GA date.

> Doron >