On Sat, 2005-11-26 at 10:34 -0500, Jeff Spaleta wrote: > 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? I haven't said anything about repository configuration being command-line only -- just that it's not in the flow for getting updates. I don't want the casual user who's not going to understand how to deal with bugs falling into updates-testing just because they're confronted with a set of confusing checkboxes. > 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. Frankly, rawhide _isn't_ safe for the casual user and I'm surprised to see you even insinuate that it could be. :) updates-testing should be much safer, but I still think there's a degree of familiarity that's required to make it actually effective for someone to use it. > > 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. I actually need to make sure that we're using the same logging here as yum > 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. I think this has more likelihood of being abused than useful. Also, doing it in a reasonable fashion is difficult due to the variety of formatting that's really needed. As the tools get better and easier to use, though, I think you'll find less "use this random URL to use bar's repository" and more "go to bar and add them" when we have the ability to more easily do "click on repository, get asked about adding it" Jeremy -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
