Comments inline: JR
Brock Pytlik wrote: > 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. > There is a cost to doing the check and 1 day seems a reasonable refresh period, if we get more folks asking for this we can add in a shorter refresh period. Of course if you are particularly keen to check for an update you can just run the Update Manager directly from System->Administration->Update Manager >>> 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? > Ok - the use case is clear, I for one would like to have the UMN shut down after the recheck so its one less thing running on my system, and I reboot daily as a mobile user so this is not an issue. Lets add in another gconf key for UMN to allow this behavior to be controlled: gconf key: shutdown_after_update_icon_clicked - default it should be set to False, so it will not shutdown after user clicks on the UM Notification icon. Setting this key to True will result in the UMN shutting down after the user has been notified of an update and clicks on the UpdateManager Notification icon. By default the UMN continues to run checking for further updates after the icon has been clicked. > 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 > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
