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

[Vratislav Podzimek]

On Fri, 2012-11-09 at 12:27 +0100, Miloslav Trmač wrote:
> On Thu, Nov 8, 2012 at 9:40 PM, David Lehman <dlehman at redhat.com> wrote:
> > 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?
> 
> Well, perhaps thing B shouldn't have been changed incompatibly in the
> first place.  I realize that's an ideal that is impossible to achieve,
> but we are rather cavalier about changing interfaces without adequate
> notification.
> 
> I've been told that the F18 Anaconda work was for some time done on a
> single rawhide snapshot; after ~2 months the snapshot was updated -
> and it took weeks to get Anaconda working again against the new one.
> 
> That sounds rather bad.  Yes, anaconda is special, but it is not
> _that_ special; if updating for core platform changes (without any
> major known change happening in the mean time) requires weeks of work
> on anaconda, there will be other software that will require weeks of
> work to update.
I'm afraid anaconda _is that_ special. AFAICT there is no other piece of
code that directly interacts with dracut, systemd, Network Manager, gtk3
(and GObject introspection) and many other components that change quite
often. If there is such code, I'd be happy to look at how its developers
handle such changes and take a lecture from them.

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic