On 02/07/2014 02:10 PM (US Eastern Time), Andreas Tille wrote:
Hi Bhaskar, On Fri, Feb 07, 2014 at 12:14:31PM -0500, Bhaskar, K.S wrote:[KSB] Since a GT.M release is frozen for all time once it's released, one answer is as many releases as we have disk for. Another answer is that although we periodically get e-mails from people with five and ten year old releases, we normally consider releases to have a two year window of peak use, and maintaining three years' worth is a good number. That will probably translate to about ten releases.[KSB2] GT.M users often have multiple GT.M releases installed on their systems. Here is a representative example: A system hosts the systems of record for the medical records of both Clinic A and Clinic B. Clinic A uses release 1 of GT.M, whereas Clinic B uses release 2 of GT.M (perhaps because Clinic B came online later and used the latest release of GT.M then available, whereas Clinic A never upgraded). Release 3 becomes available and has new functionality that both clinics want. Here is an upgrade scenario: * Set up replica of the production database of Clinic A with GT.M release 3 and real-time replication from the current instances to the new instance (so that if a patient record is updated on the Clinic A system of record in GT.M release 1, it shows up right away also in the replica using release 3). The replica of Clinic A is created by taking a backup of the release 1 instance and upgrading it - no dump/restore is required. Also, the two instances can share the same source code for the routines of Clinic A, but the object code for the same source code is different for each release. * Once satisfied that the replica of Clinic A on release 3 is stable, at convenient time, switch over so that the system of record on release 3 is replicating to the system of record on release 1. The switchover itself can be scripted and executes in seconds. After the switchover, in the event Clinic A on release 3 has issues, a simple switchover reverts Clinic A production to release 1. * Once satisfied that Clinic A on release 3 is stable, shut down replication to the release 1 instance, and eventually delete it. * Upgrade Clinic B the same way. In this representative scenario, there are three GT.M releases concurrently installed and in use on the system, with no change to the OS version.Thanks for this verbose explanation. Is this a vote to keep three fis-gtm versions at the same time inside a Debian release? If I understood Luis correctly we are at first targeting at some educational VistA installation. From your explanation it seems to become clear that if you want to support a Clinic you somehow need a support company that might perfectly profit from our fis-gtm packages but the maintenance of all previous versions need to be put on their shoulders. We should not try to push the burden on the Debian release team / security team. That's simply not how Debian works.
[KSB3] I don't think there will be an excessive burden on the Debian release / security team. Let me propose that we see how it goes and if it looks like it will be a burden, we'll think of a different strategy.
As there is not a reliable way to automatically ensure that a GT.M release is no longer in use, we strongly recommend that a new GT.M release always be installed in a new directory.I think this item became clear and we are using versioned dirs.Because bugs in GT.M are very infrequently encountered in production,I'm sorry but as long as any software is not written by the magical good of infallibility it will have bugs. So we need to be prepared to fix it and we should try to keep the burden for people who need to do the actual work at a bearable amount.
[KSB3] The upstream team will fix material bugs in a timely fashion. Yes, GT.M has many bugs that the development team knows about, but remember that GT.M has been in daily production use since 1986, and available as free / open source software since 2001. But the track record for the last ten or more years is that it is very rare for users to encounter bugs in production environments. So again, let me propose that we see how it goes in practice.
Regards -- Bhaskar -- GT.M - Rock solid. Lightning fast. Secure. No compromises. _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.