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@xxxxxxxxx> 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? -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel