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

[David Lehman]

On Thu, 2012-11-08 at 17:20 +0000, "Jóhann B. Guðmundsson" wrote:
> On 11/08/2012 05:14 PM, Stephen John Smoogen wrote:
> > On 8 November 2012 10:06, "Jóhann B. Guðmundsson" <johannbg at gmail.com> wrote:
> >> On 11/08/2012 04:37 PM, Matthew Garrett wrote:
> >>> On Thu, Nov 08, 2012 at 04:32:29PM +0000, "Jóhann B. Guðmundsson" wrote:
> >>>
> >>>> Or if I rephrase why could not the community continue to use
> >>>> Anaconda in it's form that it existed in F17 until the "new
> >>>> installer" was *completly* done?
> >>> Because nobody in the community did the work to make the F17 Anaconda
> >>> work in F18?
> >>>
> >> This also touches on "Who's responsible for an feature"
> >>
> >> Just recently FESCO decided *for* Kay that he was responsible to ensure the
> >> migration related docs and what not kept working for the name change of
> >> configuration files that takes place in systemd ( which was not even a
> >> feature ) Applying the same logic here the Anaconda developers themselves
> >> would have been responsible keeping the "old code" working until the new one
> >> was ready to completely replace it.
> >>
> > Your problem is that you are assuming a lot of things without actually
> > doing any legwork to find out what anaconda does. Anaconda does a lot
> > of probing of hardware which changes when kernels change. Anaconda
> > requires changes when dracut changes APIs. Every release requires
> > changes in what is blacklisted and what is not blacklisted. It
> > requires dealing with the usual multiple changes in python apis and
> > such. It has other changes due to EFI or secure boot or other
> > features. None of them are trivial and doing them in parallel is
> > usually not possible.
> 
> Not that your response is relate to who's responsible for making those 
> changes, but is that not a fundamental flaw in the installer and it's 
> design?

No. It is an inevitable consequence of the feature set demanded of the
Fedora OS installer.

If thing A must be able to set up and configure thing B and thing B
changes in ways directly related to said configuration, how can you
reasonably expect thing A to continue to be able to configure thing B
without corresponding changes? Magic?