Jim Gray
----- Original Message ----- From: "Frederick D. S. Marshall" <[EMAIL PROTECTED]>
To: "Hardhats" <hardhats-members@lists.sourceforge.net>
Sent: Wednesday, April 27, 2005 5:06 PM
Subject: [Hardhats-members] Seattle OpenVistA R&D Meeting
Dear Hardhats,
Thursday, May 12th to Sunday, May 15th, WorldVistA is holding a small technical meeting to verify, package, and release OpenVistA version 4. Since this will be a technical meeting, it will not make a good venue for those seeking an introduction to VistA, or looking for installs on their laptops or discussion sessions, or even to socialize or make plans. It will be an old-style, heads-down, hard-working meeting focused on achieving results as efficiently as possible.
This release is a turning point in how OpenVistA is developed, and will finally set in motion changes we have been planning since 2001:
1) OpenVistA will be kept in sync with VA's FOIA release of VistA. It will be a superset of FOIA VistA. All VA FOIA functionality will be included. In addition, verified development done outside the VA and not yet adopted by the VA will also be included; this add-on work will be done in the form of KIDS patches applied to the FOIA, so that the exact relation of OpenVistA to FOIA VistA will remain close and explicit. The OpenVistA 4 release will include the most recent FOIA as well as the FOIA with the OpenVistA patches applied, so that OpenVistA adopters can run comparisons easily.
2) OpenVistA will be a decentralized product consisting of three classes of changes. Class I changes are those issued by the VA, and will constitute the core of OpenVistA. Class II changes are those issued by WorldVistA, and will constitute the verified superset around which we build our software lifecycle. Class III changes are those made outside these two verification shops. Class III changes that meet the published standards or can easily be made to do so may be submitted to the responsible development team for possible inclusion, testing, verification, and release as a Class II change.
3) OpenVistA development will be coordinated with the VA, so they always know where our focus of work is, and to ensure that our work remains compatible with theirs. We will emphasize joint ventures whenever possible.
4) OpenVistA will be developed modularly by teams, as VA VistA used to be. The code base for each package will be the responsibility of its team. Whether developed by its team or by outside volunteers, changes to a package will only be released as part of OpenVistA with its team's review and approval, after field testing, and with the verifiers confirming that the change meets our standards.
5) OpenVistA will be written according to the VA's own Standards and Conventions document, including MOP-UP and related ancillary development standards. We intend to adopt the next version of the SAC, the one developed several years ago but not yet adopted by the VA. The development standard we adopt will be one of the products of the Seattle meeting.
6) OpenVistA will be verified to published standards that meet or exceed the VA's own verification standards. Thus, all OpenVistA patches will be VA-ready, to make it easy for the VA to adopt OpenVistA work whenever they choose to do so. The OpenVistA verification standard will be one of the products of the Seattle meeting.
7) OpenVistA will be documented to published standards that exceed the VA's own documentation standards. There are a number of ways in which VA code is inadequately documented from a troubleshooting and support perspective, so OpenVistA's documentation standard will be tightened to make OpenVistA easier to support than FOIA VistA. The OpenVistA documentation standard will also be a product of the Seattle meeting.
8) After the meeting, changes to OpenVistA will be routed through the patch module on OpenForum. Patches, whether Class I (VA) or II (WorldVistA) will be sent by the patch module to subscribers for them to install to stay up to date. After each new FOIA release we will release new snapshots of OpenVistA as reference points and to simplify installation for new adopters, but the focus of development will shift from releases to patches, a much more dynamic and verifiable mechanism for change.
9) The first release of OpenVistA will be fairly close to the FOIA. We are aiming first of all to formalize and strengthen the software development lifecycle, and only thereafter to stress that lifecycle with rapid development.
10) At the conclusion of this meeting, the resulting code will be ready for pre-alpha (non-production) testing, and we will be looking for volunteers to do so. We anticipate a cycle of testing and patching before we will be ready to go to alpha test (in a production setting). Our first patches after release will be driven by this testing, and so will emphasize bug fixes and accelerating the software lifecycle (tools for testing, verification, analysis, troubleshooting, etc.).
11) One of the main reasons for creating OpenVistA 4 is to settle on a common, verified platform into which we can integrate all the useful, verifiable code developed by various OpenVistA teams over the last two years. Some of it has already been donated to WorldVistA, more has been promised, and we will shortly be soliciting donations of code from throughout the community. All of this is essentially Class III, i.e., unverified code, so it will have to be evaluated, tested, documented, and verified before we release it. When it is released, it will be released as patches to OpenVistA 4, and will be sent from OpenForum to subscribers, so there will be no confusion about the difference between the Class III donations and the Class II verified and released code.
12) In short, at present all code that is in OpenVistA 2.51 (the previous release from two years ago) but not the FOIA is Class III, and so is all the unofficial OpenVistA code that has grown up around the community in the meantime. This meeting transforms OpenVistA to a mix of Classes I & II, and sets in motion the process to convert Class III work from around the community into Class II patches to OpenVistA.
For the next few days, I will be sending daily email messages about this meeting, OpenVistA, and related topics in preparation for the meeting in Seattle. To make OpenVistA 4 and its lifecycle possible, we need to decide on a license for OpenVistA 4 and its patches. That will be the subject of tomorrow's email.
Sincerely yours, Rick Marshall President, WorldVistA
PS: At the Seattle meeting, work will also continue on developing a web front end for VistA. As that is R&D, no specific deliverable is expected at the end of the meeting other than a status update.
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members