status of up2date and rhn-applet

[Jeff Spaleta]

On 11/26/05, Jeremy Katz <katzj at redhat.com> 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