RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1098321 - Text and buttons on 'reclaim space' version of Installation Options now inconsistent
Summary: Text and buttons on 'reclaim space' version of Installation Options now incon...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.0
Hardware: All
OS: All
unspecified
high
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On: 1014671
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-15 19:32 UTC by Adam Williamson
Modified: 2014-07-24 19:19 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1058867
Environment:
Last Closed: 2014-07-24 18:35:43 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
screenshot of the problematic dialog (138.89 KB, image/png)
2014-05-15 19:33 UTC, Adam Williamson 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1058867 0 unspecified CLOSED Text and buttons on 'reclaim space' version of Installation Options now inconsistent 2021-02-22 00:41:40 UTC

Internal Links: 1058867

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.
Note You need to log in before you can comment on or make changes to this bug.