Community
Participate
Working Groups
In testing the "Avialable Software Sites" view I find myself wanting to "Remove all" and select just the sites I want to check for updates. I also wonder if we might consider categorizing sites to separate those sites explicitly added by the user vs. the zillions of associate sites added because they're referenced by another site.
> In testing the "Avialable Software Sites" view I find myself wanting to "Remove > all" and select just the sites I want to check for updates. I think this is symptomatic of a problem in our "check for updates" strategy and loss of the knowledge of which IU's pertain to which update sites. See discussion in bug #234213. >I also wonder if we > might consider categorizing sites to separate those sites explicitly added by > the user vs. the zillions of associate sites added because they're referenced > by another site. > This is another symptom of the undue burden we're placing on the user. And you're a power user! Marking this bug M5 as we have other bugs (such as Bug 218534) that will be looked at during this milestone regrading this dialog. However, I'm honestly hoping a better story in bug #234213 will help point us to a UI that just seems to work for what you are trying to do.
cc'ing Darin and myself as this is a constant problem we encounter (needing to remove all of the sites and just add the one site we want to work with). Even having the delete key work would be of interest to us. :)
(In reply to comment #0) > In testing the "Avialable Software Sites" view I find myself wanting to "Remove > all" and select just the sites I want to check for updates. I also wonder if we > might consider categorizing sites to separate those sites explicitly added by > the user vs. the zillions of associate sites added because they're referenced > by another site. Looking at this now. I think your case is not typical, in that you are deciding during testing to only check certain sites for updates. In bug 234213 and others the claim is that a major advantage of p2 is that you shouldn't need to know...it will search all the sites and build the best configuration. Also, we don't currently have any API for knowing which sites the user added explicitly, we only know what is enabled/disabled at a point in time. I still think we can help you because in bug 250316, there will be some improvements in the way this list is presented. For example you could sort/separate the disabled/enabled sites, sort by name or URL, etc.... (In reply to comment #2) > cc'ing Darin and myself as this is a constant problem we encounter (needing to > remove all of the sites and just add the one site we want to work with). Even > having the delete key work would be of interest to us. :) This I think is a much more common use case than Simon's, and more reflective of an SDK user. You want to add some known thing to your system and you know where you want to get it. You want to see only that stuff when installing. Would you mind reading the ideas/discussion in bug 250316 comment 16 and providing any opinions?
marking this fixed >20081222. I've done what I can on the UI side. - You can now sort the sites by enabled/disabled in the pref page which at least lets you see the visible and non-visible ones in a group. - the delete key works - if you were removing/adding because you wanted to look at software from only one site, then you can use the new combo in the install new software wizard. I still can't really help you on check for updates. Please add your thoughts to bug #234213. There are still some usability things I need to do in the new pref page (like let you enable and disable a bunch of sites at once), but I'd rather have separate bugs for issues with the new UI.
