3.5 Time-frame: pushing feature freeze

[Doron Fediuck]

----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: board at ovirt.org, devel at 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 at redhat.com>
> >> To: "Doron Fediuck" <dfediuck at redhat.com>, board at ovirt.org,
> >> devel at 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,n,z
> >>
> >> 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.
> 

And I agreed we will not be flexible for next version, but currently
most teams are not ready yet. This is the feedback we got in the sync
meeting and it cannot be ignored.

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

The original planning assumed this may happen, so it had sufficient
slack. Once the release page is updated I'll send an update.

> > Doron
> > 
> 
>