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

[Adam Williamson]

On Thu, 2012-11-08 at 15:19 -0500, Bill Nottingham wrote:
> Matthew Garrett (mjg59 at srcf.ucam.org) said: 
> > Patches that cleanly decouple Anaconda from the entire software stack 
> > that it runs on top of would probably be received with open arms, but 
> > nobody who works on it has any idea how to implement them.
> 
> In fact, this is what has been done in anaconda over the past couple of
> releases - Anaconda migrated from having its own boot and init
> infrastructure to using system-provided items such as dracut and systemd.
> But that's complicated work, and while you're doing that migration, you're
> doing a lot of arbitration as to what bits are in generic dracut, what
> bits are in generic systemd, and what bits remain in anaconda. And during
> that process, you are *very* tied to the version of the underlying system,
> until the work is fully complete and there is a defined separation of
> features into each layer.
> 
> This, incidentally, also is why running the F17 installer on F19 isn't
> practical.

I think this whole subthread took a crazy left turn a ways back and is
_way_ into the weeds by now.

I'd put things more strongly than Bill: what's been happening in
anaconda lately is the precise opposite of what Johann suggests, and
that's exactly the right direction.

We don't want to have an installer stack that's completely independent
of the rest of the distro. I don't think anyone would take patches to do
that, really. We've been trying to do exactly the opposite.

Let's look at the practical examples. anaconda used to have its own
partition inspection code, its own loader stage, and its own network
management code and UI. Over the last few years, all of those have very
deliberately been killed and replaced with bits of the main distro. The
partition stuff was replaced by libparted; the loader was replaced by
dracut; and the network code was replaced by NetworkManager.

Again, this isn't an accident, it's a very deliberate plan. One of the
whole points of the Fedora philosophy is that we're supposed to share
and reuse work and code as much as possible. We're not supposed to write
five independent versions of everything at all. The fact that anaconda
team had to maintain their own loader (which did pretty much what dracut
does), their own partition code (which did pretty much what parted does)
and their own network code (which did pretty much what NetworkManager
does, only not as well) was a problem, not an advantage. It meant we
were duplicating a whole bunch of effort to get inconsistent results.
anaconda team was wasting time maintaining a bunch of network code that
wasn't as good as NetworkManager in the first place (ditto for the other
two examples).

The overall strategy of the anaconda team has been to try and reduce
their maintenance burden; they'd reached a point where they were almost
running full tilt just to stand still - they had so much unique code to
maintain that it took almost all their resources just to keep it working
and up to date. They couldn't work on actually improving anaconda, it
was the best they could do just to keep it at the level it was at.

So they deliberately went out and aimed to reduce that burden, and using
existing code like dracut, NM and parted was just a part of that plan.
newUI is another part of that plan - it's a lot of work now, but the aim
is that it's less of a maintenance burden than the old UI code when it's
done. The ultimate goal is that an anaconda team with the same resources
will be able to devote much less time to just keeping a giant codebase
working, and more time to enhancing a smaller codebase.

So no, our installer absolutely is not independent from the rest of the
distro, it's not intended to be and it shouldn't be. It's deliberately
designed to reuse components of the distribution as much as possible,
and the goal is if anything to increase this over time, not decrease it.
The maintenance burden of adjusting to changes in those components it
depends on is non-zero - which is where we came into this side track -
but that's not a problem. It's non-zero, but it's much lower than
duplicating all those components from scratch, only worse.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net