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

[Matthias Clasen]

On Thu, 2012-11-08 at 18:15 -0800, Adam Williamson wrote:

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

I agree 100% that it is right for the installer to use the system
infrastructure for the things it needs to do. That is a much needed and
very welcome change.

I still think there would be room for shrinking both code base and the
system dependencies if the installer focused on its core responsibility
- getting the bits on disk. That is an important and very high-risk
operation - why do we need to complicate the program doing it by also
making it responsible for creating users, configuring firewalls,
timezones, etc etc ? Those are all things that can (and imo should) be
done in the much safer and easier-to-debug post-install environment.

Maybe that is a design discussion for a different installer, anaconda
has always been a 'fat' installer, and it doesn't look like that is
going change.