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

[Adam Williamson]

On Fri, 2012-11-09 at 21:11 +0000, "Jóhann B. Guðmundsson" wrote:
> 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

Well, both models have been in use in the software industry for decades,
and there are generally agreed pros and cons to both. The biggest cons
of feature-based schedules are that the release cycles tend to get
longer and longer because no-one feels any urgency to ship and instead
just start packing in more and more features, and that users don't have
a reliable schedule to follow in planning their deployments. Of course,
if we delay our supposedly-time-based-releases too much and too often,
we can wind up with all the cons of both approaches and none of the
pros...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net