Bug 1098321

Summary: Text and buttons on 'reclaim space' version of Installation Options now inconsistent
Product: Red Hat Enterprise Linux 7 Reporter: Adam Williamson <awilliam>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED WONTFIX QA Contact: Release Test Team <release-test-team-automation>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.0CC: anaconda-maint-list, duffy, g.kaviyarasu, jonathan, vanmeeuwen+fedora
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1058867 Environment:
Last Closed: 2014-07-24 18:35:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1014671    
Bug Blocks:    
Attachments:
Description Flags
screenshot of the problematic dialog none

Description Adam Williamson 2014-05-15 19:32:07 UTC 
+++ This bug was initially created as a clone of Bug #1058867 +++

The revision to the partitioning workflow that was discussed in https://bugzilla.redhat.com/show_bug.cgi?id=1014671 has been implemented in current Rawhide and RHEL 7. I love the new version, it's a big improvement.

As it was implemented, an inconsistency has been created. If you leave the Partitioning radio button at 'Automatically configure partitioning.' and click Done, but you don't have sufficient space available for us to do a hands-free autopart, you still see a version of Installation Options. It says this:

"You don't have enough space available to install Fedora. You can shrink or remove existing partitions via our guided reclaim space tool, or you can adjust your partitions on your own in the custom partitioning interface."

but the button that leads to Custom Partitioning was dropped from the dialog as part of the workflow change. The only buttons are "Cancel & add more disks" and "Reclaim space". Mo did not actually envisage this in her mockups.

As discussed in #anaconda today, there are two ways this could possibly be addressed:

1. Tweak the "guide text" and the "Cancel" button label to make it clear to the user that they can cancel out of the dialog to add more disks *or* to switch to custom partitioning.
2. Just restore the "Custom partitioning" button to the dialog.

Mo was broadly arguing in favour of option 2, and I was broadly in favour of 1 (yes, you read that right :>)

We both agree that there are advantages and disadvantages to either approach. Case 1) keeps the logic flow clean - you choose automatic or manual partitioning on the disk selection screen, and all your following choices are made in relation to that choice. This is what I really like about it.

But Mo points out that it makes things harder for a user we're calling the "snoozing partition pokemon", who just clicks through on autopilot until they hit an error condition but *once they hit an error condition*, wants complete control. In case 1), this person has to follow a somewhat unwieldy flow (hit Cancel, change the "Partitioning" choice, hit Done again), and it makes the 'logic' of the Cancel button less clear than it is in the current design (you now have two sensible reasons to cancel - 'add more disks' or 'switch partitioning method').

Case 2) confuses the logic flow a bit more, because you can now change your mind about your partitioning style choice from the IO dialog, even though you already made an explicit choice on the previous screen, and I worry that this will confuse non-pokemons. But it is definitely a better workflow for the "snoozing pokemon". It also has the advantages that it is what was in the mockups, it's something we already had before rather than something new, and it keeps the logic of the Cancel button clear (you'd really only want to Cancel to change disk selection).

--- Additional comment from Adam Williamson on 2014-01-28 11:43:10 EST ---

For reference, the original post about the re-design is http://www.redhat.com/archives/anaconda-devel-list/2013-October/msg00064.html , and we're in case "RECLAIM DISK SPACE POP-UP" here. The mockup seems to be inaccessible ATM.
Comment 1 Adam Williamson 2014-05-15 19:33:22 UTC 
Created attachment 896047 [details]
screenshot of the problematic dialog
Comment 4 RHEL Program Management 2014-07-24 18:35:43 UTC 
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.
Comment 7 David Cantrell 2014-07-24 18:57:01 UTC 
During the planning phase for RHEL, we read through hundreds and hundreds of very long and exhausting bug reports.  Each of these has to be evaluated and resources allocated.  Bugs with escalated GSS customer cases attached receive higher priority, likewise bugs from partner companies receive higher priority.

This bug report is (a) minor, (b) non-critical....the installer does not crash, (c) cosmetic...you won't lose data with this defect, (d) has a pm_score of 0 which means that product management does not care about this problem for this release, and (e) has no customer cases cases attached which means that no customer in the field has actually had this problem to the point of calling support.

With these 5 reasons AND the fact that this would be a UI change, we have to make the decision about whether or not a fix is worthwhile for 7.1.  No customer has reported it, so there's that.  What about the impact to make this change?  Well, it would put a large burden on the translation team.  Is that really necessary now for something that is cosmetic and that no one is reporting as a defect?  Probably not for 7.1.  We have to devote our resources to more critical issues for 7.1 (RHEL-7 is gaining 2 new architectures in addition to everything else we have to do).

Please do not take a devel_ack- personally.  This bug actually got significantly more triage time than others because I thought it was possible to work it in with the other UI fixes that need to happen in 7.1.  I will also ask that you do not assume that opening a bug report against RHEL-7 automatically means it will be fixed as you describe.  That's not how bug reporting works and I know you understand this.

I appreciate your testing efforts on RHEL-7 because we've never received that much testing efforts from Fedora-focused associates on RHEL before.  It was quite helpful in the final run up to 7.0 and I hope that this devel_ack- does not discourage from continuing to provide feedback.  Remember that RHEL is extremely conservative with regards to changes.  It has to be.  The lifetime of the product requires that.  Things that are easy to fix in Fedora are often times extremely difficult or impossible to change in RHEL.
Comment 9 David Cantrell 2014-07-24 19:19:06 UTC 
Yes, RHEL has a state for bugs like that.  They just rot.  The problem is that there are too many bugs to ever resolve everything.  Part of the changes for RHEL-7 were to start making better use of the planning phase and that means to start saying no to more stuff up front.  Saying no up front sets the expectations more clearly.  In past RHEL release (6, 5, 4, 3....), we would say we'd try to address a bug for a release but if it didn't make it, we'd move it to the next release.  But the problem with that process is that the reporter would then assume it would be addressed in the next release.  More often than not it wouldn't be addressed and the bug would advance, yet again, to the next release.  Sometimes bugs would get pushed forward for so many years that eventually we'd be at a point where the change would be allowed because of the state of the product at that time.  In that case, we're given a clear reason that we can close the bug.  That process is not at all effective.

The idea behind the RHEL planning phase is that we will say yes or no to bugs.  There is a floater state of Devel ConditionalNAK, but you have to be careful when you use that because you still need to reach a yes or no on that bug.  The ConditionalNAK is primarily for situations where you are waiting on upstream or waiting on hardware or something like that.  But not for things like "well, if we get some time we can maybe probably do something for this, but I don't know what."  The correct thing to do for those bugs is to say no.

This does mean that for RHEL-7's lifetime, there will be more bug openings and closures, but that's ok.  RHEL needs that.  We were in the situation of too many open and not enough closing.  If we're not going to do it we're not going to do it.  And priorities for RHEL change with each point release.  We cannot commit to 7.2 work now because we have no idea what priorities will exist for 7.2.

Dupes actually help increase visibility and feed in to the planning phase, so closing bugs as no can help increase a bug's chances of gaining a devel_ack.  Think of all the people who search BZ and see something filed and then stop there.  Seeing it in BZ does not imply it will be addressed, but people assume that.  We could go years thinking no one cares about an issue when really GSS has been assuming that a particular low priority bug would be addressed in a point release.

Also remember the RHEL customer vs. the Fedora customer.  They are very different animals and what is high priority for Fedora may not be high priority for RHEL.  That doesn't mean it's not a bug, it just doesn't affect the RHEL set of users like it might affect the Fedora set of users.