Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Toshio Kuratomi
a.badger at gmail.com
Fri Nov 9 17:52:59 UTC 2012
On Fri, Nov 09, 2012 at 09:49:00AM -0800, Jesse Keating wrote:
> On 11/09/2012 09:35 AM, 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.)
> >
> >
> >
>
> In that context the plan would have had to be do all the "bring the
> code base forward into the next Fedora environment" work twice.
>
Correct. But while this is a problem for the anaconda team, it may be the
least-bad for Fedora overall. Then again, there might be an alternative
that is even better.
-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20121109/5fc2a446/attachment.sig>
More information about the devel
mailing list