Padraig O'Briain wrote: > > > On 12/01/08 19:28, Brock Pytlik wrote: > [snip] >> >> If the user changes the refresh period, to be shorter than the time >> left to the next check under the previous policy, shouldn't the >> timeout be changed or another call added to the idle list with a >> shorter timeout? For example, if I set the refresh period to a day, >> wait till one minute after the refresh is happened (so the next >> refresh is set for 24 hours) then change the refresh period to be >> every hour, I shouldn't have to wait 24 hours before the hourly >> refresh period takes effect. >> >> > This cannot happen. The shortest refresh period is 1 day and the > maximum that we wait for is 1 day; see line 352. This seems like code that's written to be broken in the future when specs change. I see no reason that the shortest refresh period should be a day going future. Personally, I might like to have it be an hour, or 15 mins if I'm really excited about trying new bits. I also happen to think the maximum waiting of a day is broken as well, but I'm not interested in fighting that battle now. I do think that to put code in that's explicitly dependent on never having a refresh period shorter than 1 day begs to introduce bugs in the future. > >> Regarding your comment about terminating the update manager notifier, >> does that mean if: >> a) UMN notices an update and pops up the icon >> b) I click on the icon to see what updates are available >> c) I decide I don't want any of those updates at this moment and I >> cancel UM, or quit it >> >> then I no longer get notifications of updates until I ... >> reboot/relogin/? If so, that seems like broken behavior. I can't tell >> whether your comment means "we know this is an issue but we're not >> fixing it in this change set" or "we don't agree this is a problem." >> > The behavior is as you describe. > > The reason that this is not addressed is that we do not have a > consensus that this is broken behavior. > To be clear, let's try a hypothetical example and see if I understand what you're saying isn't broken behavior. On Dec 2nd, I boot my system and get notified that there's an update to random_package. I choose not to install that package at that time because it's not critical and I have work to do, so I cancel UM. I leave my system running all the time in general, so I don't reboot or log out. Now, Dec. 3 comes along and a new OS build is released that I do care about because it fixes bug XYZ, but I don't know it's been released because I'm not subscribed to the right email aliases (like most of our users). Because I have had UMN notify me once already, I think that UMN will notify me when any new updates are available, let alone huge changes like a new OS build. In fact, I will never receive an notification of updates available again until I reboot or re-login, which could be months given the general stability levels Solaris has.
How is this not broken? As a side note, I'll point to OS X's equivalent feature which let's me tell it go to away for now, and the next day, it's back reminding me about the updates. That is the behavior I think we want, or something similar. Brock > Padraig >> Thanks, >> Brock >> >> >> Padraig O'Briain wrote: >>> The webrev, http://cr.opensolaris.org/~padraig/ips-5188-v2/ fixes >>> the following bugs: >>> >>> 5174 updatemanagernotifier should be nice(2) >>> 5188 Tidy up required in updatemanagernotifier >>> 5198 updatemanagernotifier should re-read config files >>> >>> Note that we still terminate updatemanagernotifier after the user >>> has clicked on the icon. >>> >>> Padraig >>> _______________________________________________ >>> pkg-discuss mailing list >>> [email protected] >>> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss >>> >> _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
