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

[David Cantrell]

On Thu, Nov 08, 2012 at 05:56:31AM +0000, Matthew Garrett wrote:
> On Thu, Nov 08, 2012 at 06:31:20AM +0100, Kevin Kofler wrote:
> > Adam Williamson wrote:
> > > The new anaconda UI and related features are more or less entirely the
> > > cause of the slip.
> > 
> > This shows that those changes should not have been done, or at least not in 
> > this way.
> 
> It turns out that software development is hard. It's especially hard 
> when you have a hugely complicated system with no central management and 
> no real incentive for most of the skilled workers to cooperate on 
> sections of the project that influence each other. It's nigh-near 
> impossible when you have the same set of people tasked to simultaneously 
> stabalise an upcoming release and do the development work for the 
> forthcoming release. The miracle isn't that Anaconda is taking longer 
> than desirable. It's that it's as close to finished as it is.

Thanks, Matthew.  I'd also like to clarify some misunderstandings I've heard
directly or indirectly from other people.  These are paraphrases of what
I've heard.

1) "The installer team did not anticipate the amount of work required."

Not true.  As with our other major changes, we new it would be absolutely
impossible to deliver all functionality in a single release.  So from the
beginning we were planning to stage the newui work across multiple releases.
This is _in addition_ to other components undergoing major and fundamental
changes.

For the newui work, initial discussions started at FUDCon Tempe, through the
year, and then again at FUDCon Blacksburg.  After that, more design work
continued, soliciting for user feedback as much as possible.

This is why we began communicating our work early and involving groups like
Fedora QA as early as possible.  Our false assumption was that we were all
on the same page as to what would and would not be ready for F-18.  To me it
seems a lot of these slips are caused by things we thought everyone knew we
could push to F-19 but really we wanted in F-18.  So that's communication
and setting expectations.  We can do better with that in the future.

2) "Just stop everything, move newui to F-19, and ship the F-17 installer."

This just delays what we are going through right now until the F-19 cycle.
We need to identify the failings at some point and work to improve/change
them.

This also assumes the F-17 installer will work as a drop-in for F-18, which
it won't.  So where should we be spending our engineering resources?

3) "The new installer should have been tested more!"

I completely agree!  Which is why we were getting early test builds done
during the F-17 cycle and working to get people testing the installer then.
The main problem is that no one _wants_ to test the installer.  It's a
utility.  A necessary step to getting Fedora on your system.  Testing it
isn't sexy to a lot of people.  We can't force people to test it, we can
only make it available and ask for help.

And to those early testers who have helped and provide useful feedback,
thank you!

4) "Anaconda releases shouldn't be tied so closely to Fedora releases."

Well, ok, but it is.  No matter how distant we make the installer from a
distribution release, we're always going to be tied to the release process.
That's where people use it.

The biggest impact this has for us is that our real test and development
cycle happens between the devel freeze and RC.  Most people don't notice it
because we are not doing things like newui, but that's how it's been for
years.  It works ok for maintenance, but large scale things like this become
more visible and people get frustrated.

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