On 11/26/05, Jeremy Katz <katzj@xxxxxxxxxx> wrote: > Why would you want to not download updates from all repositories you > have configured? Or at least see what's available. The fact that the > updates come from multiple repositories is a detail that I don't think > users really want to / should need to care about. updates-testing Not being able to pick and choose for updates-testing via the gui is going to mean less people in a certain class of user who are not going to use updates-testing. For a casual user who files a bugreport and then needs to give feedback on a package in updates-testing or rawhide that claims to fix the issue...shouldn't there be a way for them to selectively eat from updates-testing/rawhide... without dropping to the cmdline? We've already seen Mr. Lee call for more usage of the update-testing, but this isn't going to happen if casual users can not eat from the tree selectively with the primary tool presented to them. Some people who want to test a gimp update are not going to want to eat a test kernel update as well. If you are intent on streamlining the pup interface to the extent that individual channels/updates can not be selected/de-deselected please make it impossible for pup to pull updates from updates-testing at all with it. If you take away granular control from pup, updates-testing AND rawhide become much less safe for the casual user of a normal release. > I've always personally found this to be a bit of a waste and just > another click which isn't really needed -- I asked for updates, when > they're done, get out of my way :) Instead of a summary window.. will pup be generating a log with timestamps that include packagename,version and repository source? Once you start adding repos that replace Core or Extras, it becomes somewhat important for the user to know where to bitch about problems with certain applications. Where the package is from very much matters if there is a problem. And there really needs to be a casual user oriented way of seeing that information so they can drive bugs and questions to the correct repo. On the topic of notifications.... would it be possible for have room in the notification metadata for a "repo notification"? When a person contacts a repo for the first time, a chance to display a short message as defined by the repo...similar to a short website faq? A lot of people in #fedora who end up adding repos do so by following google'd recipes and never actually read the repository faq or about page. As a result they get very frustrated when the repository replaces Core packages or they find they have missing deps because they didnt include all the repos required. A first contact dialog on the client tools like pup could help avoid some of this frustration. Such a message could give a short about text and information about communication channels such as mailinglists and bugzilla for that repo. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
