About the FLAP Phase Two Prep Sprint

Yesterday, we completed the monthlong, intensive sprint to update our first release of Fileman 22.2 from March 2013 to produce MSC Fileman 22.2. We in this case consisted of Don Creaven, Zach Gonzales, George Timson, Sidney Tarason, David Whitten, OSEHRA Product Manager Mike Henderson, and me, with FLAP documenter Kathy Ice working in parallel on the manuals (see below) and FLAP system manager David Wicksell working hard to keep our servers accessible during this period of trials and tribulations. The focus of this update was on:

1) revising the codebase to meet OSEHRA's new Contributed Software Attribution Policy (http://www.osehra.org/sites/default/files/TD-04-01_ContributedSoftwareAttributionPolicy.pdf);

2) folding in George Timson's past year and a half of work, as captured in MSC Fileman 1051;

3) additional testing, bug fixes, and verification, not only of the new features and bug fixes but also of the work we did during FLAP Phase One (from October 2012 through March 2013); and

4) cleaning up versioning and distribution artifacts to get a clean release of Fileman in a consistent state.

So far we've produced what looks like a clean RSA file for MSC Fileman 22.2, based on testing so far. We also have a draft OSEHRA Technical Journal article and a draft NOTICE file, both of which I'm upgrading and refining today. I'll also be creating a compliant LICENSE file, and Christopher Edwards is helping me think through the details to fully meet the spirit of that attribution policy as well as its letter. To say MSC Fileman 22.2 has a complicated provenance is an understatement.

I'm double-checking OSEHRA's OSHERA M-Code Primary Developer Checklist (http://www.osehra.org/sites/default/files/osehra_primary_developer_checklist_1.pdf) to make sure all these wee ducklings are in order. Next I'll do likewise with OSEHRA's Procedures for Contributing Code and Performing Code Reviews (http://www.osehra.org/sites/default/files/codecontributionsandreviewprocedures.pdf) to do likewise. When I'm satisfied all this is in order, I'll submit the code to the OSEHRA Technical Journal (http://code.osehra.org/journal/journal). That submission will include the documentation from the Fileman 22.2 submission the FLAP team made in 2013, which is no longer entirely up to date, but is still mostly correct.

This will close out the sprint, but it won't close out the work to be done for FLAP Phase Two Prep. Prep work will continue along two tracks.

First, we need to update the manuals to finish the work that was cut off when VA abruptly ended FLAP Phase One (in the wake of the departure of Roger Baker, Peter Levin, and Mike O'Neill from VA). That will include production of a new User Reference Manual and completion of the in-process Technical Manual. We also need to update the manuals to cover the past year and a half of George's work, and to review his and Sam's and others' previous work in FLAP to make sure the manuals are complete. These will be submitted to OSEHRA as each manual is completed. We'll focus early on the Release Notes and Install Guide, since test sites will need these documents first. FLAP documenter Kathy Ice has spent the past month overhauling the manuals to prep them for this update; now that the coders are done coding, we can go through our checklists and spreadsheets and send her documentation updates for everything we identified.

Second, given VA's stated interest in a KIDS build and distribution for MSC Fileman 22.2, we're going to find out if this can safely be done. There is a chicken-and-egg problem between KIDS and Fileman, since KIDS depends on Fileman to, well, file all the distributed data into the database, using Fileman's Transfer-Merge and DIFROM Server extensible engines, so using KIDS to update the DIFROM Server and Transfer-Merge is . . . conceptually and architecturally challenging, like doing brain surgery on yourself. But VA is confident it can be done and is understandably interested in folding Fileman into the KIDS installation-tracking framework, so we're going to give it a try and see what happens. Needless to say, this will get extensively tested. If this second track works, we can say that you will be able to use either the RSA or the KIDS distribution to update an existing Fileman installation, but for stand-alone Fileman (which would have no KIDS yet) or for a virgin Fileman install (which would have no Fileman yet, and therefore any KIDS present would be inoperative) you would have to use the RSA approach for installing Fileman. We'll talk more later about the installation and upgrade process.

For now, let's get this codebase properly submitted to OSEHRA.