Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #224472 +++ Creating this bug to differentiate between showing nested requirements in the "Installed Software" page and showing them in the wizards. Some of the logistics and core dependencies are different, hence this separation. I'm cloning it so that interested parties will remain cc'ed and I'll bring forward the relevant suggestions/comments from the other bug.
From bug #224472 comment #27 (and originally from bug #240125) Suggestions/comments from duplicate bug: >Expected: >- the wizard's "Install" page shows the dependencies that are being pulled in, >and from what repositories (I don't care about the mirror). The page should >also note the total download and install size of all the dependencies. >If this creates too much clutter on the "Install" page, the plug-in dependency >details could be moved to their own page, which could be skipped by selecting >"Finish", or the list of installed items could be a tree with "plug-in >dependencies" a collapsed top-level item... <snip> >But then again: If I understand correctly P2 was created to also smoothly >support meta update sites that provide plug-ins from multiple sources, such as >a "plug-in central repository". In that case I would definitely want to know: > >- what's being installed >- who's the provider / creator >- under what licence >- under what copyright >- whether signed or not
What I see happening based on the new workflows in the install dialog and on the desire to be able to deselect/select multiple items in the wizard before resolving is something like this: - page 1 of the wizard basically confirms the user selections, lets you see the descriptions as you select things, etc. - page 2 of the wizard is shown after resolution. It includes the detailed, nested list of what is being brought in during the install. If there is a resolution error or you otherwise don't like what you see, go back to first page - page 3 is licenses This workflow can then solve several separate issues: - page 1 is a good place to introduce "suggested/optional features" per bug #247342. User makes additional choices without the clutter of the requirements - the transition from page 1 to page 2 is where resolution occurs rather than doing it on every selection change in the wizard (bug 247985) - page 2 gives the detail requested in bug 224472 and bug 240125 I'm marking this M3 to work on the metadata requirements implied and determine the basic strategy, but it's not clear this will make M3 as it depends on the provisioning plan being able to satisfy some detailed queries.
Changing bug dependency. What's needed in the core is to be able to query a ProvisioningPlan in the same way we can query a repo or a profile.
Moving to M4. Requirements on core have been identified, the UI part will be completed in M4.
Adding dependency to bug #227675 as this affects which required IU's are shown in drill-down. See also bug #252366. Once we implement this bug, we'll have the same problem as the installed page has.
Working on this right now. My original plan was to use the user's originally selected IU's as the roots of the tree and expand into showing groups that were required, and optionally show all of the IU's that are required. But we have a funny case in bug 252638 where the user-selected IU is not going to get installed, but something else is. This is most likely a bug, but it points out to diagnose bugs such as this, we may need to choose the visible roots in a different manner, so that we can understand what is being brought in that had nothing to do with user selection (and why).... Or that we need an alternative view (the first comment suggested an optional page, perhaps this could be the last page of the wizard so that it could be skipped after the license page?). This view could show every single IU that is to be installed but we'd have to have some way of describing why it was in the list (who referred to it) or else it's not meaningful.
(In reply to comment #6) > My original plan was to use the user's originally selected IU's as the roots of > the tree and expand into showing groups that were required, and optionally show > all of the IU's that are required. > Talked to Pascal about this issue. In bug #218055 he is looking at providing an "Actual Change Request" that is returned along with a provisioning plan after resolution. So if something will be removed, or something won't get added, as a result of resolving the plan, this is communicated to the UI. What this means is that rather than using the user's originally selected IU's as the roots of the tree, we would use the roots returned in the "ActualChangeRequest." > But we have a funny case in bug 252638 where the user-selected IU is not going > to get installed, but something else is. This is most likely a bug, but it > points out to diagnose bugs such as this, we may need to choose the visible > roots in a different manner, so that we can understand what is being brought in > that had nothing to do with user selection (and why).... In bug #252638, the problem was that the user's selected item did not resolve, but there were other items that were going to be upgraded as part of the resolution. The UI could not tell this happened. Because the selected item had optionality, the plan was OK, the plan contained some IU's, but not the user's IU. With the introduction of the "ActualChangeRequest" the UI can detect that nothing the user wanted can be installed. This will also give the planner a place to add error status surrounding the thing that won't be installed.
Fixed in HEAD >20081125. Note there are still related problems that are open: - visibility of features, bug 227675 - better description of what is to happen and failure cases, bug 218055 - ability to better tell the user that something they wanted to happen isn't going to happen (ActualChangeRequest discussed in comment #7) The main issue - that the user should be able to drill down and see what is to be installed - is fixed. What happens now: Page 1 - the user selects the things to work with (install, uninstall, update) Page 2 - resolution is performed and the user is shown the list of items as well as any groups (features) they are pulling in. This drill-down goes to the group level, not all the way to the plug-in level. This is the same navigation used in bug #224472. Since we didn't get any feedback in that bug regarding level of detail, I'll consider the level of detail appropriate. If there is a strong requirement for us to drill down all the way to the plug-in, I'd like to see someone open a bug and describe the use case. In the install new software wizard, the user starts at page 1. In the update/install wizard, we preselect the things to work with (since the user already selected them in the Installation Information page) and open the user onto page 2. The user can go back and change the selections if desired.
these changes will not be in the 1125 I-build, just in the nightly build, and in the following i-build.
verified on WinXP, Build id: I20081209-0100 during test pass
