Hello, thank you for this nice summary. Yesterday I have sent an email to get final decision in our team which of these solutions we will use to Fedora 23. Seems like most of us (including me) agreed on small string change #4. On Tue, 2015-10-13 at 16:46 -0400, Máirín Duffy wrote: > Proposed Solutions: > =================== > > (These were discussed both in the github pull request #377 > https://github.com/rhinstaller/anaconda/pull/377 and in #anaconda on > October 1) > > 1) New Bucket for ESPs > ---------------------- > > PR: https://github.com/rhinstaller/anaconda/pull/377 > > Put all EFI system partitions into a separate 'bucket' in the > partition > list. > > This is jkonecny's PR. He created a separate "UEFI partitions" bucket > that the UEFI partitions would go in. The ESP wouldn't show up in the > existing system. > > downside: the same ESP shows up in the UEFI partitions bucket > multiple > times, one time for each OS root we know it's associated with. it's a > bit jarring to have multiple entries for the same thing. > > downside: in the F23 timeline this was a lot of change late and there > was worry it might introduce other unforeseen issues. > > > SUMMARY: > > We were worried the multiple entries per ESP would be too problematic > and thought #3 might be a more polished solution with a minimal > amount > of change. I agree with you. I think this will be nice way for the final patch to Fedora 24 but not now in final freeze of F23. > 2) Hide all firmware-boot related partitions > -------------------------------------------- > > Treat all firmware-boot related partitions as being details of the > boot > process and hide them from the user. > > "except then people would want an even more custom partitioning, that > allowed them to do things to everything" (clumens) > > "i think there's a reasonable argument that by 'custom partitioning' > what's really expected is 'custom layout of OS bits'" (adamw) > > > SUMMARY: > > With our userbase, the loss of flexibility / control was going to be > problematic and would escalate the issue in terms of UX. It's also a > major code / functionality change. So this change is pretty big / > complex and would have a lot of other effects we'd need a lot of > planning around. IMHO I don't like this solution. It seems complicated to me. I think hiding a partition is not the right way. > 3) Silently fail to delete ESPs when user checks off 'delete all' > ----------------------------------------------------------------- > > PR: > https://github.com/rhinstaller/anaconda/pull/383 > > Patch Demos (via adamw shakycam): > - Windows/Fedora: https://www.youtube.com/watch?v=e4PIOf8K538 > - Fedora/Fedora: https://www.youtube.com/watch?v=PgpOXgI1f-c > > When 'delete all' is clicked, don't delete shared devices, and don't > delete bootloader partitions if there are unknown partitions (for > Windows multiboot case) or if the device is shown in more than one > root > (for Linux multiboot case.) If there are no unknown partitions and we > know the ESP isn't shared, it will be deleted with delete all. > > Basic assumption here is that we assume ESP is in use if there's > other > stuff on the system we don't know about. So it's a more defensive > policy > than the current one. > > If you really want to delete it, it'll moved to "Unknown" bucket and > then you can then hit the "-" button to delete it. Takes a little > extra > effort, but still possible to delete, and you really are explicitly > demonstrating you want the ESP specifically gone at that point. > > Note that this option is different than always keeping the ESPs in > unknown from the start (proposal #5,) because you get to see the ESP > in > line with the OSes we know it's associated with before you do the > delete > all action. > > > SUMMARY: adamw and mizmo think this is probably the best course of > action from a UX POV. jkon supports the patch too in the PR. > When I looked on this in more detail I'm afraid it's also big change to the code, for true this looks to me more invasive then my first patch now. Parts of this PR could be used as final patch though. > > 4) Simple string change in the dialog to warn users > ---------------------------------------------------- > > Patch: > https://github.com/rhinstaller/anaconda/pull/377#issuecomment-1448082 > 51 > > <dlehman> let's just put a little warning text when removing an ESP > (or > when removing anything) and leave it at that > > > SUMMARY: This requires people to read, and they aren't always good > about > doing that. > This seems to us as the best solution for the F23. It isn't invasive at all and the user will be warned. You are right when you said user didn't read but when you take in count number of bugs with this issue to this date it seems most of the users are not affected (not so many PCs are using UEFI now). This could help some users before they do it wrong. I'm more afraid of users which are used to this behavior and you change it without any warning when you take in count how long this is standard behavior of Fedora. > > 5) Move ESPs to the Unknown Bucket > ---------------------------------- > > <mizmo> then you wouldn't even have to special case unknown > <mizmo> because the esp wouldn't be under the fedora OS bucket > anymore > so when you do delete all ... it doesnt get deleted > <mizmo> if there's a single unknown partition => all ESPs go to > unknown > bucket > <mizmo> if there's more than one known OS => all ESPs go to unknown > bucket > <mizmo> so ESP only shows up under an OS if it's unshared > > downside: extra clicks to delete ESPs, but kind of good in that you > don't delete unless you're sure. > > downside: potential for ending up with multiple ESPs if people don't > use > the autopart button. (mizmo noted that in usability tests majority of > users did use autopart and then modified from there.) > > downside: you never get to see the ESP associated with the OSes we > know > it's associated with. > > > SUMMARY: Option #3 is just a better solution. > I don't think this is the right way. > > 6) Do nothing > ------------- > ... > > > SUMMARY: There are two separate bug reports over this issue (BZ > 1183880, > BZ 1177976) and the UX could stand some improvement so from my > (mizmo) > UX POV I don't recommend this option. :) > I don't recommend it either. > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
