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

[David Cantrell]

On Thu, Nov 08, 2012 at 06:15:55PM -0800, Adam Williamson wrote:
> 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).

Just as a clarification here.... anaconda has used libparted for a very long
time.  It is one piece of the larger storage backend code.  The libparted
changes that came with our storage backend rewrite a number of years ago was
that we began relying on libparted to do more for us.

I'll also point out that we both own the parted component in Fedora and are
upstream contributors and co-maintainers.

> 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.

-- 
David Cantrell <dcantrell at redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT