Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

["Jóhann B. Guðmundsson"]

On 11/09/2012 05:35 PM, Toshio Kuratomi wrote:
> On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote:
>> As far as Anaconda reverted in the future, I'm confused as to
>> when/where this became a requirement.
>>
> I think he's saying this because:
>
> 1) Features have a section for contingency plans.
> 2) In this particular case, we're slipping schedule because the NewUI
>     feature has a point where there stopped being a contingency plan.  We
>     passed that point before being aware of all of these issues that need to
>     be fixed in order to release Fedora.
>
> Being stricter about having viable contingency plans for features like
> this (ones that require coordination and can potentially block us if they
> aren't done/done correctly) is one possible way to address this type of
> situation in the future.
>
> Others are to alter the "time-based" release philosophy for certain
> features (We are going to have Feature X in Fedora 19.  If it isn't ready,
> we're going to slip the release date until it is done.)  To only let in
> a feature with no contingency plan only when it is code complete and can be
> evaluated outside of the Fedora tree first (anaconda devs state that they do
> not actually have the manpower to implement this style of solution).
>
> -Toshio
>
> - Note: I considered adding "have a longer release cycle" to the list of
>    alternatives but it's not clear that we wouldn't still get into this
>    situation (FESCo/releng/QA finding out at beta freeze that Feature X lacks
>    certain capabilities that are considered essential while the team
>    responsible for the feature had considered that it was something that
>    could safely be put off until the next release.  Being unable to revert
>    the feature at that point and so having to code the missing capabilities
>    on a rushed schedule at that point.)

Actually the more I think about it the more I come to the conclusion 
that "time-based" release is not the right way for the project but a 
"feature-based" release is.

We just just have feature submission deadline, feature approval 
deadline, then we work on approved features until they are done and then 
give releng/marketing x time to prepare for release. that means we can 
have 5 month release cycle or 7 or 9 month release cycle which gives us 
the flexibility to integrate features properly into the release before 
delivering into the hands of our end users and we don't have to worry 
about "contingency plans" anymore

JBG