Currently, we are scheduled to re-freeze for F18 beta later today. As I understand it, fedup status was one of the main reasons for unfreezing last week and I figured it would be best to be clear on the current state of fedup so that there are fewer potential surprises later.

I don't have any huge objections to re-freezing but it's not just my call. My questions are:
* If we unfroze mostly due to fedup status, is the current status far enough along to justify re-freezing?
* If not, what are the criteria for re-freezing? What constitutes a good-enough upgrade process such that F18 beta can re-freeze in preparation for release with less risk of farther slips in the release process?

== Current State with Git ==
Using the most recent code for fedup and fedup-dracut as of the time of this writing, my understanding of the current state is as follows:

=== Building initramfs ===
It is possible to build the initramfs needed for fedup using lorax source from [https://github.com/wgwoods/lorax a temporary lorax fork]. I tested this earlier today - the upgrade.img is built using the packaged version of fedup-dracut, currently in updates-testing. An upgrade using this initramfs functions according to what one would expect from the current packaged version.

As far as I know, the changes to lorax have been submitted upstream and are waiting for review before we get a new lorax build to test. Based on my current understanding, this will not have much effect on lorax's current functionality but could increase the size of the DVD due to another ~ 20MB initramfs being generated for upgrades.

I believe that this method for building the initramfs needed by fedup is acceptable to releng once the lorax patches are merged upstream and an official build is available.

=== Fedup ===
Using fedup from git, it is now possible to do an upgrade with a kernel version change and end up with a bootable system that appears to function (I haven't done any heavy testing on the upgraded system yet but I don't have any reason to believe that there are major problems). Most of [https://bugzilla.redhat.com/show_bug.cgi?id=873459 873459] has been fixed with the changes to fedup but the fixes are not available in packaged form at this time.

The latest version of fedup from git is also capable of working with the .treeinfo generated by lorax and pungi.

=== Fedup-Dracut ===
Doing an upgrade with an initramfs built from the latest fedup-dracut in git, it is possible to complete an upgrade. There is still an issue with the upgrade logs not being written to disk at the completion of the upgrade. I have a hacky patch which forces sync after upgrade to workaround the issue but this is not in git. I have not received a response as to whether or not this patch is desired or if there is another solution.

== Current State with Packages ==
The current packages for lorax (f18), fedup (f17) and fedup-dracut (f18) do allow for the upgrade process to complete if a suitable test repository is available. However, there are many missing fixes in these versions and an upgrade with only these version will not complete successfully unless the kernel is excluded.

== Potentially Release Blocking Issues with Fedup ==
I'm not currently aware of any potentially release blocking issues for the most recent version of fedup in git. There are two issues which could have the potential to cause problems but I don't see either one as clearly blocking or not

=== Upgrade Logs ===
With the most recent version of fedup and fedup-dracut from git, logs from the upgrade process are not written to disk after the upgrade has completed. There are proposed solutions and an available (but somewhat hacky) patch but no solution has been pushed to git yet.

==== Related Bugs ====
* [https://bugzilla.redhat.com/show_bug.cgi?id=873459 873459 - Upgraded system does not reboot if a kernel upgrade is part of the upgrade]

=== Upgrade Progress ===
While there are upgrade logs, it is currently not possible to see any detailed progress of the upgrade while it is going on unless the upgrade debug shell is enabled or a serial console (with some debug options) is used.

Personally, I don't think this is a release blocking bug for beta but it is something to be aware of.

==== Related Bugs ====
* [https://bugzilla.redhat.com/show_bug.cgi?id=873144 873144 - pressing Esc kills plymouth screen]
* [https://bugzilla.redhat.com/show_bug.cgi?id=869061 869061 - No output to journal after double-switch-root]

=== Packaging Status ===
This is not something that I'm worried about but it could technically block release. The packaged versions of lorax, fedup and fedup-dracut are not capable of completing an upgrade and do not represent an initramfs build process which is acceptable to releng. Newer versions of the packages in question would fix this issue and again, I'm not really worried about it.

==== Related Bugs ====
* [https://bugzilla.redhat.com/show_bug.cgi?id=872047 872047 - fedup-dracut builds do not exist in F18]
* No bug filed for lorax functionality yet - I will file one if we freeze and the stable version of lorax is not capable of building the initramfs for upgrades. In my opinion, this would have no trouble being accepted as a blocker and pulled to stable after freeze starts.

== Current Risks and Unknowns ==
Because of the short time frame since fedup has been testable, there hasn't been a whole lot of testing at this time. As such, this is one of the larger risks - if there are other potential release-blocking issues that haven't been found yet. Everything has been going well for my testing so far and I haven't heard of any major issues during upgrade which I haven't discussed already in the ticket.

However, most of my testing has been limited to VMs and there has been little effort thus far to upgrade bare metal systems or increase the breadth of the hardware used for upgrade testing (RAID, the usual variety of hardware).

Due to the way the fedup is implemented (using dracut, yum and systemd), I have no reason to believe that there are major issues lurking here that wouldn't affect a majority of systems or VMs but it is always possible.