#944 Revert to old anaconda for F18
Closed None Opened 11 years ago by drago01.

= phenomenon =

The new anaconda UI has been approved as a feature for Fedora 18. But apparently it requires more time to become complete and get enough testing after that.

= background analysis =

We already slipped because of it and according to the Roadmap (found here: https://fedoraproject.org/wiki/Anaconda/Task_Status ) list some features that are considered release blocking like upgrades to be done by F'''19''' Beta.

I also have concerns regarding getting proper QA for late landing installer features. Bugs in the installer can not be easily fixed post release like ones in other packages (we don't spin new media post release).

Also refer to the discussion in #941

= implementation recommendation =

We should revert to the old UI anaconda and try again for F19. There is no reason to try to get it into F18 if the costs and risk are that height, we should simply wait one more release and leave the anaconda team more time to finish things. Features do have contingency plans for this exact reason.


Reverting would likely take /more/ time than fixing the existing issues. A lot of the delay is due to pretty significant changes in dracut land meaning lots of the infrastructure we relied upon just not working. That's well outside the UI, and if we reverted back to F17 we'd have to re-fix all those issues in an older code base with unknown number of new bugs.

Replying to [comment:1 jkeating]:

Reverting would likely take /more/ time than fixing the existing issues. A lot of the delay is due to pretty significant changes in dracut land meaning lots of the infrastructure we relied upon just not working. That's well outside the UI, and if we reverted back to F17 we'd have to re-fix all those issues in an older code base with unknown number of new bugs.

"with unknown number of new bugs." Well its not like we have a limited number of bugs in the new codebase. We don't have any (public?) code for upgrades for example. So there is a non trival amount of yet to be written code that is supposed to be working in time for beta. And as I have already written above late landing features receive less testing and we cannot fix anything post GA. So we simply do not have enough time to do proper QA.

Also if reverting the feature takes more time than implementing missing releases features (that are scheduled for F19 according to the roadmap) then the feature should never have been approved with a contingency plan that can not be executed in practice.

Replying to [comment:3 drago01]:

Also if reverting the feature takes more time than implementing missing releases features (that are scheduled for F19 according to the roadmap) then the feature should never have been approved with a contingency plan that can not be executed in practice.

The contingency plan that was approved is in http://fedoraproject.org/wiki/Features/NewInstallerUI#Contingency_Plan - essentially "no contingency plan". I'm not sure whether everyone realized the implications of this decision at the time of feature approval, but from the formal point of view insisting on the contingency plan does not support reverting the feature.

Replying to [comment:1 jkeating]:

Reverting would likely take /more/ time than fixing the existing issues. A lot of the delay is due to pretty significant changes in dracut land meaning lots of the infrastructure we relied upon just not working.

In addition to this, there's at least one other feature that depends on Anaconda which is not implemented in F17's Anaconda. So additional development work would be necessary. It's not just "revert and fix it to work again."

From 2012-09-05 FESCo meeting: this proposal was rejected by general acclamation in the course of discussing FESCo ticket #941.

Login to comment on this ticket.

Metadata