Tech Forum

Is there some perceived benefit in issuing Patches (to MLS 3.0 for instance, which seems to attract them like flies) on the Sunday?

Is it just that the MLS demons send them out at the very last moment Friday night?

We have two units using the chapel complex and try to keep out of each other's hair at midday - and then along comes the Patch. This would make little difference were it not for the fact we have been instructed to run a Send/Receive always before using MLS.

On Sunday we have very little time in the clerk's office before Sacrament and wasting what we have on SRs and Reboots would be more fun on a Tuesday night???

I can't see doctrine in it - what was the Policy about?

WenU wrote:Is there some perceived benefit in issuing Patches (to MLS 3.0 for instance, which seems to attract them like flies) on the Sunday?

Is it just that the MLS demons send them out at the very last moment Friday night?

We have two units using the chapel complex and try to keep out of each other's hair at midday - and then along comes the Patch. This would make little difference were it not for the fact we have been instructed to run a Send/Receive always before using MLS.

On Sunday we have very little time in the clerk's office before Sacrament and wasting what we have on SRs and Reboots would be more fun on a Tuesday night???

I can't see doctrine in it - what was the Policy about?

I don't know anything about a policy. However, I'd have to guess that patches are released on Friday. I'd suggest that if you are squeezed for time on Sunday, that you make arrangements to have someone drop by the building on a Saturday (if it's convenient) and do a S/R. This will take the heat off.

You didn't mention if you're using high speed DSL or dial-up. If you're on DSL then these patches don't usually amount to much and don't always require a reboot.

No no - we are on DSL but we have 30 minutes to do everything that I may need to do between PEC and Sacrament, without leaving the PC unattended with MLS open. So I just have to sit there wasting precious time on - nothing - due to a scheduling practice that I think would be better set for earlier in the week.
It may seem handy to wait until the end of the week and do it on Friday - but remember Friday in Utah is Saturday in Australia and the Pacific Islands. But why does all this have to be convenient for the people who work on the systems? Isn't the User the focus of the efforts?

Note: Post edited to remove disrespectful comments.

Techgy wrote:You didn't mention if you're using high speed DSL or dial-up. If you're on DSL then these patches don't usually amount to much and don't always require a reboot.

The speed of the connection does not affect whether the update requires a reboot. Every update in recent memory has required a reboot.

The above applies to patches downloaded during the Send/Receive process. On the other hand, downloading the full install from mls.lds.org and installing it when MLS is not running never requires a reboot, so it is actually a much quicker process, assuming the stake technology specialist or someone with access to mls.lds.org can download the installer to a flash drive and get to the building. Of course, in many areas that may not be practical, and so the best option is to let MLS update itself.

WenU wrote:But why does all this have to be convenient for the people who work on the systems? Isn't the User the focus of the efforts?
Ahhhh Silly me Being closer to SLC they are probably more sacred. I just have a vision of countless ward clerks around the World having a similar scheduling problem because nobody in SLC bothered to think about the consequences of such a simple oversight.
And it IS a very simple oversight.
We don't come to Church on Sunday to see what 'they' dreamed up on Friday night.

One of my favorite quotes is from Marvin J. Ashton, who said:

Perhaps the greatest charity comes when we are kind to each other, when we don’t judge or categorize someone else, when we simply give each other the benefit of the doubt or remain quiet.... Charity is expecting the best of each other.

Let's examine the practice of Friday updates from this perspective.

First of all, I know for a fact that the User is indeed the focus of the efforts of the MLS development team. I know that they are a team of careful, experienced, intelligent developers.

Patches are released to benefit MLS users. These provide fixes to bugs, many of which were reported by users who are anxious to get the fixes. Many of the reports of bugs would tend to be made on Sunday or Monday, and if the MLS development team responds as quickly as possible, they would probably be able to get the fixes done and releasable by Friday.

I don't know any more than you do why they release on a Friday, but I really doubt that it is an "oversight" or that they "dream up" something on Friday night. Suppose that they have a bug fix ready for release on Friday. Should they hold it back and release on Monday? This will delay the fix getting into people's hands a full week for many people who do their Church work primarily on Sunday. Wouldn't it be kinder to get the fix in their hands sooner?

It could well be that the people outside of Utah are the primary focus of this practice. After all, in Utah a clerk probably only lives 5 minutes or less from his building and can easily go during the week to update MLS. But in some areas of the Church it takes over an hour to get to the Church building and may involve significant cost. Releasing on a Friday would actually be considerate of these people, since the alternative would indeed be a week delay.

I assure you that the MLS development and support teams are very aware of the needs of the world-wide Church and carefully plan to take into account the variety of needs. They're not perfect (I believe that's true of all of us ), but any problems with updates are not caused by a lack of concern for users around the world.

Alan_Brown wrote:The speed of the connection does not affect whether the update requires a reboot. Every update in recent memory has required a reboot.

The above applies to patches downloaded during the Send/Receive process. On the other hand, downloading the full install from mls.lds.org and installing it when MLS is not running never requires a reboot, so it is actually a much quicker process, assuming the stake technology specialist or someone with access to mls.lds.org can download the installer to a flash drive and get to the building. Of course, in many areas that may not be practical, and so the best option is to let MLS update itself.

I wasn't inferring that the reboot had any impact on speed. I was responding to issues, namely that it takes a while to do the updates and finally that not all updates require a reboot.

Users that are fortunate enough to have DSL and use it for the MLS program don't spend as much time in the S/R as those who use a dial-up method.

Sorry for the confusion.

WenU wrote:But why does all this have to be convenient for the people who work on the systems? Isn't the User the focus of the efforts?
Ahhhh Silly me Being closer to SLC they are probably more sacred. I just have a vision of countless ward clerks around the World having a similar scheduling problem because nobody in SLC bothered to think about the consequences of such a simple oversight.
And it IS a very simple oversight.
We don't come to Church on Sunday to see what 'they' dreamed up on Friday night.

I think you are also not giving thought to potential business processes that may currently exist at the Church that dictate a Friday release for MLS updates. You have to imagine that there are countless servers responsible for storing all of the Church data, others for receiving and sending the communications each time MLS connects to the Church via the internet, and still more servers to hold and distribute application updates. None of us knows the weekly schedules the automated processes must run on. Working in the business world, I do know that such processes do exist on specific days of the week that may seem odd but are necessary.

I also think Alan is right that the developers are very concerned about getting the bug fixes out as soon as they can to benefit all clerks around the world. I imagine the MLS developers work hard every day of the week, hoping that they can finish the release so that it can be released by Friday, and not make everyone wait an entire week more to get the software update.

Perusing this discussion has brought up a question I never thought about before. I probably wouldn't even address it but for the experiences we have been having with the MLS 3.0 upgrade. Thus -

Normally when an upgrade is made a notice pops up that a reboot is required. However I believe that during the numerous patches that were made during the 3.0 process, several were sent out that did not require a reboot. So, would the only way to know for sure that an update (patch) has been made would either be to note a specific item that changed or rather by the "build" number?

Which brings up the following question - do (did) the MLS guru's put patches out to previous versions that never would have been noticed other than noting the build number?

Just curious I guess since I never even noticed the "build" number till it was brought up during this thread.

Jim

Pilotfly wrote:Normally when an upgrade is made a notice pops up that a reboot is required. However I believe that during the numerous patches that were made during the 3.0 process, several were sent out that did not require a reboot. So, would the only way to know for sure that an update (patch) has been made would either be to note a specific item that changed or rather by the "build" number?

I know for certain that the first broad MLS 3.0 update (labeled as beta 5, 12 Jun 2009, Build 15688) required a reboot. I have never seen any of the MLS 3.0 updates that did not require a reboot, but I can't be sure about all of them, since a couple of them I installed on all the computers in the stake using the full installer.

But I have never seen a case in the last several major revisions of MLS where an update was applied during a Send/Receive without a quite obvious message saying something like "An MLS software update is being applied to your computer," followed by reboot instructions. I really doubt that an update sneaks in during an MLS transmission. In most units, multiple clerks may do a Send/Receive, so some other clerk may end up doing the update.

But to answer your question, if an update happens that you didn't know about, the build number and/or revision date is a reliable way to determine if a new version has been installed. The build number and rev date are on the bottom of the MLS login screen. The build number is always available on Help > About.

The reason I asked if updates were done without a reboot notice is that there was definitely an update (patch) done that I didn't reboot. I noticed that on the stake computer I was not getting the June Finance report nor was I able to see the second quarter Quarterly Report. I called Salt Lake and related the issue. The MLS folks stated they knew there was a problem and they were working on it. (This was discussed in another thread about the quarterly report and finance report).

Later (last week) I stopped into the stake center and did some work. Did a send receive and noticed that when I looked, lo and behold, both the June Finance Report and access to the second quarter report was now available. I never saw a notice about a patch nor did I see a "reboot" note. So that is what got me wondering if there is always a reboot, or if a better indication (if one pays attention) is the "build" number.

Jim