Medsphere.org: VistA code repositories at Medsphere.org

Up to Discussions in Help and Feedback

6,549 Views 9 Replies Last post: Nov 7, 2009 10:53 AM by Jonathan Tai

Jonathan Tai

341 posts since
Jul 24, 2008

Currently Being Moderated

Sep 19, 2008 9:52 AM

VistA code repositories at Medsphere.org

Now that we have the main site up and running, we're turning our attention to getting our code up on Medsphere.org in a more usable format. Currently, we only offer the ability to download release tarballs, which isn't very helpful if you're trying to do actual development.

I mocked up some screenshots of what I'd like to add for a "code" section on Medsphere.org. Please have a look and reply with your comments and suggestions. Did I miss any features that we'd absolutely need? Did I go overboard (we're never going to use all this stuff)?

This first screenshot is what you would see initially when you entered the VistA Distributions code section - a list of repositories. Repositories are a collection of branches; you typically have one branch of code for each feature or bug. The screenshot here shows that each repository has a Mainline branch, which is a special branch that serves as a collection point for all of the features and bug fixes developed in other branches. Clicking on a repository name (e.g., OpenVista Server, WorldVistA EHR, or FOIA VistA) will bring you to the next screenshot; clicking on a branch name (e.g., Mainline) will bring you to the third and fourth screenshots, below.

This second screenshot is the Repository View. A list of recent branches for each repository is already shown on the initial page, but if you need to dig deeper for an old branch, you can find it here.

This third screenshot is an example of a Branch View. Like I mentioned earlier, you typically have one branch for each feature or bug, and this screenshot shows the branch view for a bug branch. The associated bug is shown in a box on the right.
A branch of code is made up of a number of revisions, shown on the left. For VistA development, we'd likely make a "commit" (save changes as a new revision) when we feel that an enhancment or bug is ready for QA. In this case, there's the initial revision where this branch forked off of Mainline, a revision after the developer felt that the bug was fixed, then one last revision to fix a problem that presumably QA found. At this point, the branch was merged back into mainline, and further development on this branch ends. The flag on the right is green, indicating that the associated bug report has been closed.

The fourth screenshot here shows the same view, the Branch View, but for a Mainline branch. The Mainline branch is a long-lived branch and serves to collect the fixes and enhancements developed in other branches, so you'll see that there are a large number of commits, and each commit has a fairly regular (and boring) commit message that just indicates what branch was merged in.

The final screenshot shows what you'd get if you clicked on a revision, the Revision View. The section on the top left shows details about the revision, including when it was committed, who committed it, whether this is a regular commit or a merge of another Revision, etc. There are also links to browse routines or globals contained in this revision. The section on the bottom left shows what changes were introduced in this revision - it's a difference between the previous revision and the current revision that you're viewing. On the right are a series of boxes that provide additional information about the revision - whether or not the routines compiled successfully, automatically generated documentation genereated for this revision, packages of this revision, etc.

Tags: vista, .org, code_viewer

Pete Johanson

50 posts since
Aug 6, 2008

Currently Being Moderated

1. Sep 19, 2008 10:09 AM

in response to: Jonathan Tai

Re: VistA code repositories at Medsphere.org

You might also want to check out TeamCity for inspiration. It's another continuous integration/build/test server software I found recently.

As for the mockups... Looks really good. Is there any sense of "branch ownership" ? If not, you could at least have a view that was "All branches last committed to by Bob" which would get the equivalent thing for some development workflows.

Are you going to mock up the other things Fireball does, like testing (both unit and Strongwind)? TeamCity I know has unit testing integration, it might be interesting to see how they handle that, etc.

Very cool!

Jonathan Tai

341 posts since
Jul 24, 2008

Currently Being Moderated

2. Sep 19, 2008 10:25 AM

in response to: Pete Johanson

Re: VistA code repositories at Medsphere.org

I will check out TeamCity.

About your questions regarding fireball... for vista, we're not going to have repository ownership because we'll likely have collaborative development on a single branch, and merging across branches is likely to be a manual (not an automated) process. For the other projects, we'll likely do it the way we do it internally with repository ownership.

I may mock up the unit testing, but that's kind of far out in the future. My first goal will be to get the vista development stuff going.

- Jon

George Timson

13 posts since
Sep 10, 2008

Currently Being Moderated

3. Sep 25, 2008 10:09 AM

in response to: Jonathan Tai

Re: VistA code repositories at Medsphere.org

Your examples, like "Issue 8019", do not correlate with our SourceForge artifact numbers.

If they did, then a list of "Issue ---, Isuue ---, Issue---, ..." would be helpful. Otherwise, this

is another nonintuitive categorization scheme. "NOIS 1234 equals Sourceforge 5678 equals MDO 9012...." Ugh.

Could we see a list of KIDS Patch names, for example, or some more meaningful headings?

Jonathan Tai

341 posts since
Jul 24, 2008

Currently Being Moderated

4. Sep 25, 2008 11:10 AM

in response to: George Timson

Re: VistA code repositories at Medsphere.org

George,

We currently use SourceForge Enterprise Edition internally, but we pay a per-seat licensing fee for it, so I doubt that we would use it for an externally (community) facing bug tracker, which is why I used different terminology ("issue" as opposed to "artifact"). While some of what you describe will be inevitable (NOIS 1234 is related to Sourceforge 5678 which affects MDO 9012), the plan is to move all of our bug tracking and code repositories for our open source projects into the open, so we wouldn't be filing bugs for OpenVista Server in SourceForge at all.

The problem with naming branches for KIDS patch names is that we will likely create the branch before we have a fix (the branch is for working on the fix), so I don't see how we can know ahead of time what the build name will be. I will try to build the associations into the web tools so that when you're looking at a "closed" branch (one that's been merged back into mainline already) it will show the associated issue in the bug tracker, the KIDS build that comprises the solution to the issue, etc. Or did I misunderstand your last point?

- Jon

George Timson

13 posts since
Sep 10, 2008

Currently Being Moderated

5. Sep 26, 2008 10:22 AM

in response to: Jonathan Tai

Re: VistA code repositories at Medsphere.org

Jon told me yesterday:

George,

If you reply to [this] discussion, you will be given the opportunity to
comment and attach multiple files. I would suggest that you attach both
the % routine and the accompanying Word document to your reply.

Note that I had intended all along to use your % routine in the "back
end" to discover the changes between two VistA "revisions", but I just
realized that I may not have mentioned % by name in my post. I'll reply
to your reply and make it clear that I intend to use %...

Thanks, George.

So here is my latest version of the "%" routine, with documentation. I have already sent this by EMail to the Medsphere MUMPSters (Sher, Criteser, Cunningham).

Attachments:

The % routine.doc (75.0 K)
%.RSA (26.6 K)

davidc

6 posts since
Nov 17, 2008

Currently Being Moderated

6. Dec 12, 2008 9:40 AM

in response to: Jonathan Tai

Re: VistA code repositories at Medsphere.org

Since you are doing revision control with bazaar for openvistaCIS anyway, and mentioned possibly moving to that for OpenVista server, would it be possible to host repositories on Canonical's launchpad.net?

Jonathan Tai

341 posts since
Jul 24, 2008

Currently Being Moderated

7. Dec 12, 2008 10:28 AM

in response to: davidc

Re: VistA code repositories at Medsphere.org

I'm actually working on doing some benchmarking/metric collection right now, but my gut feeling is that we're not going to be welcome on launchpad because the repository is going to be huge - the working copy is almost 1GB. This is because we can't really separate the globals from the routines, since the globals contain code in them that are interpreted on-the-fly.

We have (internally) discussed using launchpad for bug tracking and repository hosting, but there are two drawbacks that make me hesitate - first, we have no way to keep your username and password on medsphere.org synched with launchpad; second, we are going to need to customize the tools (such as the repository viewer) to be "VistA-aware", and that won't be possible if we're using launchpad. That said, there were a lot of things about launchpad that we liked - for example, it seems to go out of its way to make it easy for non-developers to contribue.

JohnLeo Zimmer

14 posts since
Sep 12, 2008

Currently Being Moderated

8. Nov 7, 2009 7:16 AM

in response to: Jonathan Tai

Re: VistA code repositories at Medsphere.org

Two questions:

How will the repository handle fixes/enhancements that cross distribution boundries ( e.g. the currently active CCR/CCD project )?

How about a provision for a common code base, i.e. those core features that are common to all, or most, or some distributions)?

Thank you for this effort.

GpZ

Jonathan Tai

341 posts since
Jul 24, 2008

Currently Being Moderated

9. Nov 7, 2009 10:53 AM

in response to: JohnLeo Zimmer

Re: VistA code repositories at Medsphere.org

First off, let me say that we've embraced Launchpad.net for code repository hosting rather than build out our own infrastructure, at least in the short to medium term. Code repositories for OpenVista CIS, OpenVista Server, OVID, and the OpenVista/GT.M Integration Project are all hosted at Launchpad. Launchpad.net is constantly being improved by Canonical's team, and they have been able to handle OpenVista Server's huge repository without any problems. The only thing we would gain by hosting an instance ourselves is the extra MUMPS/VistA specific tools.

How will the repository handle fixes/enhancements that cross distribution boundries ( e.g. the currently active CCR/CCD project )?

For a project like the CCR/CCD project, the easiest approach (and what they currently do) is have their own repository, then as they release (either formally or for testing), they submit a build to the various VistA distributions. The OpenVista/GT.M Integration Project works in a similar way -- we do releases, then those releases get incorporated back into OpenVista Server whenever OpenVista Server does a release. (Note: we welcome other VistA distributions to incorporate our changes as well!) OpenVista Server releases quarterly while the GT.M Integration Project releases every month or so, so when OpenVista Server releases, it consumes a number of GT.M Integration releases at once.

How about a provision for a common code base, i.e. those core features that are common to all, or most, or some distributions)?

The idea of a common code base is very important, but also very complex. There are a myriad of ways to handle it with distributed revision control tools. One approach would be that you have teams of subsystem maintainers (e.g., a FileMan Team) that creates their own repository like the CCR/CCD project and releases in the same fashion -- all of the distributions consume FileMan releases into their own repositories. Another would be to have a "core" repository that all the other distributions either merge from or branch off of. Yet another would be for each distribution to just have its own repository and cross-merge patches when desired. Much more experimentation is required before we can determine the best approach, and a high degree or cooperation between distributions is going to be key.

The community SKIDS project is attempting to bridge the gap between VistA and open source revision control tools and might be of interest. (The home page is pretty blank right now, but we're looking to post some design documents for discussion in the next few weeks.)

Go to original post

Sep 19, 2008 9:52 AM

VistA code repositories at Medsphere.org

Actions

More Like This

Bookmarked By (0)