Community
Participate
Working Groups
This bug is opened to spin out a discussion from bug #239449. Alexander said: >And one more problem looks close to this >bug: features sizes are readen asynchronously and in most cases this process >takes much more time to complete than is required for user to finally press >Install button. This mean that reading of feature sizes have no sense if user >can't see them just in time. The original intent was that if something pulled in a bunch of other installable units such that the size was much larger than anticipated by the user, the user would have a chance to cancel. I think the better approach is to better at showing the user what will be pulled in because of an install. (That is covered in bug 224472). Given that we will be reworking this area, it is reasonable to revisit whether we should show size, and why...
Another user confusion in this area is that the "computing size" job shows up in the progress view. Coupled with our poor detail in showing install progress, what happens is that you see "Install" in the progress view and then before you see any install detail, you'll simply see a bar that says "Computing Size" (Canceled). This can confuse the user into thinking that the install itself is cancelled.
Note: we added a sash between the size control and the details area per bug #242305. The visual indication for the size is pretty poor because these surrounding controls don't have borders (or in the case of the details area, the border is not on the edge). I didn't try to address this problem on the assumption that we are revamping the presentation of size in 3.5. So...if we don't change anything here, consider at least changing the layout to make the availability of the sash more noticeable.
The size computation should probably be done in a system job because it is not explicitly started by the user and the fact that there is a background job at all here is an implementation detail.
moving to M4 to work while working bug 250862
Removing milestone as I don't have a clear opinion on what to do here. I think it's best to leave it as is right now. In M4, we have added drill-down on the resolution wizard page, so that you can see the required items that are being pulled in during an install or update. So we provide more info about how "heavy" an install is. On the other hand, looking at the requirements might make the user linger at this page a little longer. I don't want to remove the information simply because some users might not wait for it. (The sizing job is a system job so the distraction in the progress view is no longer an issue.) It would be best if we could show the size of each individual item. We used to do this, but the performance is simply unacceptable. I would like to wait for a resolution of bug #225759 before making changes here.
I can't think of a time during the M5 test pass where the size got computed in time for it to be useful. I was testing and doing a lot of drill down and stuff, and never did the size fill in before I was done with the wizard, or else I saw 0K. I think we should pull the size info out of the wizards completely.
cc'ing Matt as he is looking into the core side of sizing. I won't change anything in the UI until we see what he does.
Created attachment 131453 [details] SizeComputingWizardPage I noticed recently that if you select something to install, proceed to the resolution page, wait until the size is displayed, press Back, and select more software, then return to the resolution page that the old size is displayed until the new one is calculated. The patch adds a call to updateSizingInfo() before size is calculated which returns the display to Unknown.
released Matt's patch >20090414 (thanks, Matt). In testing this, I found that the size updated as expected before I could get to the size page, but I do see how the symptom described by Matt could happen, if the sizing job timed out or otherwise got delayed. This bug was was originally opened to ask, "is the size accurate often and quickly enough to be worth showing?" I'm finding that in current 3.5 i-builds, the size is gotten much quicker than when I last tested during 3.5 M5. (esp if you have unchecked the [ ] Contact all update sites during install... box). Because we did not fix bug 225759, we will still have an issue where we will report sizes of Unknown for older remote update manager sites, because we do not carry forward the sizing info. However at this time there are many more sites creating p2 metadata now that the PDE tooling is better. So I will mark this bug fixed for 3.5 because - Matt fixed a timing bug - sizing is faster/more accurate - since 3.4 M7, most of the problems with 0 size are now marked "Unknown" - we are smarter at marking missing artifact computations as "Unknown" - we reconsidered presenting size differently and decided "no."
