Hi Please send credit card details Or type stop to be deleted from my mailing list Jamie Sent from my iPhone > On 15 Oct 2015, at 12:40 AM, Jiří Konečný <jkonecny@xxxxxxxxxx> wrote: > > 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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
