@m4rtink @kkoukiou @jkonecny @vtrefny for input.

I think we should go ahead and invoke the contingency plan. Given the Go/No-Go meeting on Thursday, I'm invoking fast-track on this.

+1 to revert anaconda web UI and punt to Fedora 40.

I don't want to put the burden of "work night shifts or we need to delay the release" on the anaconda team, so +1 to revert and punt to F40 (and +1 to fast track)

Hi, thank you for the ping.

So about the bugs:

• https://bugzilla.redhat.com/show_bug.cgi?id=2236398
  • is already merged to the code we just need Anaconda release
  • https://github.com/rhinstaller/anaconda/pull/5146
• https://bugzilla.redhat.com/show_bug.cgi?id=2238292
  • I asked @vtrefny and he should be able to provide fix today / tomorrow
• https://bugzilla.redhat.com/show_bug.cgi?id=2236398
  • This one is the most tricky one
  • We might be able to deliver the fix tomorrow but we have to discover the requested changes to the code first
  • @kkoukiou and @rvykydal are working on this right now

+1 to revert

+1 to revert

+1 revert

@jkonecny Is it possible for us to deliver the WebUI as an experimental option for Final, with the preferred and documented approach being the GTK UI?

@sgallagh not sure how exactly would you like to do that. We can I guess use boot option for that?

Status of the pending bugs:

• https://bugzilla.redhat.com/show_bug.cgi?id=2238292
  • fixes are on review
  • https://github.com/rhinstaller/anaconda/pull/5164
  • https://github.com/storaged-project/blivet-gui/pull/412
• https://bugzilla.redhat.com/show_bug.cgi?id=2236398
  • we are proposing fix to show an error to user
  • https://github.com/rhinstaller/anaconda/pull/5165

In other words, I think we should have resolved all the blockers today or early tomorrow if our proposed solution will be accepted.

I know the timing is tight this week, but the team seems to be making good progress and this feature is a big advancement. My vote is currently a 0 until I can see the results of these fixes from @jkonecny and team.

+1 revert

@jkonecny Is it possible for us to deliver the WebUI as an experimental option for Final, with the preferred and documented approach being the GTK UI?

This could definitely put us in a better place for Fedora 40 - basically:

If you just want "Fedora", you get the old tested UI
If you read the Fedora Magazine article "The new Fedora Beta installer", you find out about a boot option, and try the new installer

With the current path, I worry that even if we can resolve all the blockers, then we'll get lots of feedback about functionality but not be able to address them for GA.

The Workstation WG discussed this issue at today's meeting (at some length) and we agreed to recommend to FESCo that this change be deferred to Fedora 40. (We actually voted on this and the result was +3:2:-0.)

It would be nice if Fedora 39 could have a boot option to allow testing the new installer, to make it easier for users to provide feedback.

+1 to revert.

My best estimate of what we would need to do to have an official webUI test image is:

• A new gnome-initial-setup-webui package, which would be a build of g-i-s with the webui patches (we could make this a new source package, or just hack up the g-i-s package a bit to build it)
• A new kickstart file which inherits from the Workstation live kickstart but drops gnome-initial-setup, adds gnome-initial-setup-webui, and adds anaconda-webui
• A pungi-fedora entry, in the Spins list in the live_media dict, based on the Fedora-Workstation-Live entry from the Workstation list, but with the name changed to something like Fedora-WS_webui-Live, the kickstart set to the new kickstart file, and the subvariant changed to WS_webui

I...think that ought to be all that's needed. Well, I guess procedurally we might have to jump through some kinda hoop to approve the "new spin". Or I guess it could be part of the Workstation group rather than the Spins group, if we wanted (then it would show up in the Workstation tree, not the Spins tree).

The 'boot option' path is probably feasible but I'm less sure exactly that would entail; obviously a kernel cmdline parameter that anaconda could read and decide which UI to launch, but we'd also need g-i-s to do something similar, which might be more complex given the substantial difference between the two flows...

+1 revert for f39. I am not a big fan of yet another image.

Also, FESCo: if this proposal is approved, can you please formally designate https://bugzilla.redhat.com/show_bug.cgi?id=2238597 as a blocker bug to allow us to carry it out? Thanks.

Also, FESCo: if this proposal is approved, can you please formally designate https://bugzilla.redhat.com/show_bug.cgi?id=2238597 as a blocker bug to allow us to carry it out? Thanks.

I'm prepared to do that once we have reached +7.

Ah, well, we have in fact done that, so processing now.

We agreed to defer the change and to provide the web UI as an experimental option. That will give us as much feedback as possible, which will help us when we try again for F40. Our recommended way of doing that would be to have the new web UI as a grub menu item, as that will make it as discoverable as possible, without the need for a second image.

To be clear, my suggestion about providing the WebUI as an experimental option was intended for Final.

For the Beta timeframe, we should only be looking at shipping the GTK UI.

we could probably do the alternative image thing today, but i'm looking on that as a stretch goal, and if @kevin doesn't want to add one, maybe we won't :D The boot menu thing seems like it would definitely be a Final thing, as it's going to need some kinda interface design, and testing.

I agree with the Final suggestion for this.

I just also included this decision in today's FESCo meeting schedule, since it wasn't officially announced anywhere yet I think:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IIPQG22ZNWAGQ5BSNKNP5LNBKT45ZVBS/

Dear FESCO members,

I would like to give you feedback on this ticket voting. I don't have any hard feelings, I just want to improve the process for the future.

I agree with this ticket and decision, however, the whole process was IMHO confusing because of these points:

• If you read the description you will find that the ticket is suggesting to give time to developers to handle the bugs mentioned in this ticket. However, given the fast track nature the suggestion was completely ignored without explanation of what should be output of the voting. Another issue with fast track was that the decision and revert were done so soon that there was no place for discussing the alternative solutions (as proposed in the ticket). Also you made this decision before the GIS developer was able to react (he was offline that day). So It was without him about his work.

• The description is talking just about the blockers. However, based on the comments here, the blockers were not the reason for most +1. Especially when there were already fixes proposed to all of them. I honestly think that you should vote about what is written in the ticket and not about something else (even when the result of voting is the same). I already explained that the blockers were not the main (maybe not at all) reason for the revert multiple times to people, and I'm worried that this will spread even more on the internet. If you want to decide about stability or panic releasing, please explain it in comment or file a new ticket to avoid confusion.

These points could definitely be subjective but at least to me it lead to multiple explanations required from my side to other people already.

Other than these comments, thanks for taking care of the Fedora. I’m happy about how Fedora has the decision process and in overall with your work. I just wanted to give you feedback to avoid these issues in the future voting.