On Fri, 2012-07-13 at 15:04 +0200, Vratislav Podzimek wrote: > Please see the inlined comments below. > > On Thu, 2012-07-12 at 18:33 -0400, Máirín Duffy wrote: > > 9) Storage auto-default if Fedora and if only one non-removable disk > > detected > > ==================================================================== > Sorry, I don't understand this part. Please see questions below. > > > > This is an idea Ryan had when he first reviewed the Anaconda mockups and > > got started on the project. Right now, no matter what, you can't click > > past the hub #1 - you have to fill out information in the storage hub. > > However, a big chunk of Fedora users are setting up single-user Fedora > > installations on laptops that have a single hard drive. So, if we > > auto-detect that there is only one non-removable hard drive on a system, > > we could allow these users to click past the storage screen by > > automatically selecting the single laptop drive for install. > This means they get to the partitioning screen with the only available > drive selected, right? > > > > > This doesn't mean we wipe that single disk. Instead, we autopart any > > pre-existing free space on the disk. If that isn't enough space, we > > automatically shrinkany filesystems as needed. And how will we configure the bootloader in this case? If we don't feel comfortable removing existing partitions from disk, do we feel comfortable removing their existing bootloader without asking? > And this means that if there is only one drive and enough space on it > (shrinking the filesystems as needed), we would automatically let users > to go through the hub #1 without any note about such "brutal" > auto-partitioning done? And if they go to the Storage spoke, they will > find the auto-partitioning based layout of their partitions there? > Because if yes (and the following comment seems to be confirming my > concern), I would, as a user, strongly dislike such things happening > automatically. > > > If that isn't enough, we > > dump 'em in hub #1 with the 'attention' ! icon on the storage part and > > the user can sort it. :) > > > > 9) Icons for specialized disks > > =============================== > > > > All the advanced / network storage disks have the same network storage > > icon. It might be good to be able to distinguish between raid devices, > > sans, dasd/zfcp, etc. So we could find and as necessary develop new > > icons and hook them into the different types of storage when they're > > displayed. > > > > 10) Subscription stuff > > ====================== > > > > This is something that has to be sorted out with the subscriptions team, > > as well as the folks working on the F18 Initial Experience > > feature. :( One point that Ryan made was that the GNOME first experience > > mockups are very user-centric while firstboot is very system-centric and > > not particular to a specific user much. > > > > 11) Bug-reporting / Debug opt-in > > ================================ > > > > Jiri Moskovcak brought this up in a recent email thread with me and > > Chris - the main ide ahere is that it would be nice to let the user set > > various debugging options at install time. So they could opt in to ABRT > > and installing debuginfo packages, for example. I need to talk to Jiri > > more and get more information about this because I'm still a bit > > confused about the details. Some things that came up when Chris, Ryan, > > Mackenzie, and I talked about it today: > > > > - opt-in should be someone off hub #1 because it affects whether or not > > abrt gets installed and particular debuginfo packages get installed > > - what if it was in firstboot, and abrt / debuginfo was installed in a > > post-script? or queued up in packagekit? > > - could they be queued up in the offline updates system? > > - is there any mechanism to autoclean debuginfo packages when they are > > stale and useless? > > - smolt has a new name... this might change the smolt mockups we have > > - for oem usages of firstboot, there is a reconfig option in the old > > firstboot, it should carry on to the new one. > This applies to both #10 and #11: > I think we should just write a guide (I could write such guide as I'm > planning to write my own custom spoke) how to write Anaconda spokes and > then help other teams with the development of *their* spokes maintained > by them (probably as separate packages installed by lorax?). > > And replacing firstboot with the second run of the Anaconda UI with > unfinished spokes would allow us to use such spokes in both installation > and setting up the installed system during the first boot. > > > > > 12) Random point > > ================ > > > > - How are we handling pre-existing LUKS passwords in the new ui? > > > > > > > > I gotta go home so no time to do the to-do list summary, maybe > > tomorrow. :) > > > > ~m > > > > > > _______________________________________________ > > 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
