jmr wrote: > 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 > I think this misses the issue. The code being suggested makes a fundamental assumption that refresh period will never be shorter than 1 day. I think that's a bad thing to introduce to the code unless its absolutely necessary. So far, I haven't heard that a) it's impossible to do it any other way or b) it's ETOOHARD to do it any other way. I continue to ask, why introduce code that it's easy to see may introduce bugs in the future. >>> [snip] >> 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. > That's fine with me.
Brock > [snip] _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
