What
technical challenges faced during the rewrite
what we learned
unique challenges for an installer
history of Anaconda releases
how Anaconda is a successful open source project
Introduction
Who am I
David Cantrell
manager of the installer team at Red Hat
BS in Computer Science from Georgia Tech
My History with Linux
Projects i've worked on
Slackware Linux • AfterStep • Python • Fedora
Red Hat Enterprise Linux • anaconda • procps • GNU parted
pyparted • ISC DHCP • NetworkManager Common Desktop Environment
What Does an OS Installer Do?
Find itself
Find your storage devices
Use your storage devices in the manner you describe
Transfer the operating system to the storage devices
Prepare that operating system to boot on its own
Common Questions
How hard can an installer really be?
But can't you just use live images?
Or the cloud?
Anaconda Goals
Support the use cases of Fedora and RHEL
Look nice and fit well with the rest of the OS
Form positive first opinion of the release
Gain active contributors outside of the full time development team
Anaconda Statistics
First commit was in April 1999
More than 14 years of continual development
433 unique authors
39,253 lines of code
25,768 commits
64% of the code is Python
Highest LOC: Nov 2002 at 88,765
2nd Highest LOC: Feb 2012 at 80,562
Visual History of Anaconda
Red Hat Enterprise Linux 2.1
February 2002
Red Hat Linux 8.0
September 2002
Red Hat Linux 9.0
March 2003
Red Hat Enterprise Linux 3
October 2003
Red Hat Enterprise Linux 4
February 2005
Red Hat Enterprise Linux 5
March 2007
Red Hat Enterprise Linux 6
November 2010
Fedora 18
January 2013
Fedora 19 Beta
May 2013
Unique Development Limitations
Installer releases are tied to the OS release schedule
Bugs are "not allowed"...you can't patch the installer
Delays in our development affect the entire project
Starting the Discussion
FUDCon Tempe 2011
Brainstorming on what we could and could not do
Large decisions made, but bulk of work postponed
Large Decisions
We will continue using Python
We will use GTK+ 3.x for the graphical interface
We will continue using git and existing patch process
Back to Design
Return to design meetings later in 2011
Long meetings detailing the UX of each screen idea
Difficulty balancing advanced vs. new user ideas
Why is this part not in the open?
What's In The Rewrite
The goal was the UI, but that affects everything
New backend subsystems (except storage)
Existing GUI and TUI were removed
New GUI using GTK+ 3.x and new console-only TUI
Parallel execution of background tasks
Boot directly in to anaconda, no more loader
Iterative Design Process
Establish regular communication
Discussions should take place in one location
Summarize decisions and discussions
Explain the design decision
Communication
http://blog.linuxgrrl.com/
anaconda-devel mailing list
http://fedoraproject.org/wiki/Anaconda/
fedora devel mailing list
Basis Coding
Lower contributor barrier to entry
Indirectly marks some things as final
Helps guide your contributors
Keep Contributors Active
Your contributors are only as active as you keep them
Recognize contributions and contributors
Be careful with harsh feedback
Anaconda Rewrite Through Releases
F-16: backend rewrite
F-17: parallel development
F-18: new UI goes in to rawhide
F-19: revision and polish
F-next: ...
Reception
How did users react?
Did users and contributors listen?
Did contributors defend decisions?
Summary
Overestimate time required for everything
Communicate early and often
Software is hard, pie is good