Stream: committers
Topic: pull/review process
Sean McIlvenna (Jul 12 2017 at 21:57):
I think it would greatly benefit us all if the main FHIR repository was stored (and sourced) from github.com. I think it would be great to implement the branching/pulling/merging processes in git. Do this, we could have automated builds for each branch to ensure changes don't break builds, and even have peer-reviews prior to accepting pull requests. Are there any plans to implement these types of practices?
Lloyd McKenzie (Jul 12 2017 at 22:32):
It's on the drawing board. In general, we don't want more than one active branch as any changes to past release need to be very tightly controlled (and given the pain of going through a publication process, we'd only update if something was really critical). Right now we're experimenting with the non-build stuff having been migrated to Git. If that works well, we'll migrate the main repository to Git. And once that seems solid, we'll look at supporting pull requests, etc. from the community. One of the challenges is that we currently author resources using Excel and that's not terribly ammenable to merging given differences in saved files between Excel versions and extraneous content like what tab was active, what cell was selected, etc. that makes their way into files. So we're going to need to figure out an alternate way of saving and loading the content and that's not going to be super easy. (Hand-editing raw StructureDefinition XML or JSON isn't feasible for most of our committers and tools like Forge aren't designed to support the authoring of data types or resources.)
Sean McIlvenna (Jul 13 2017 at 15:47):
I'm not talking about updating past releases. I think those would be a branch or tag to themselves. "master" would be the "latest" changes, a branch off of master when publishing STU3 would not be changed unless absolutely critical. Additional branches off of master would be created for each major change request to the "latest", and a pull request initiated when the committer feels their changes are ready to be merged into the master branch, allowing for review and testing prior to the merge.
Sean McIlvenna (Jul 13 2017 at 15:49):
As for creating/modifying the resources and data types... Yes, a binary format like XLSX would be an issue when merging. We'd need a solution for that, for sure. XLSX is just a ZIP of XML files, though. Maybe we could add a build-tool responsible for extracting the important contents of the XLSX as XML files and storing those in the repository, rather than the XLSX file itself. It would add a couple steps for those working on the core resources, but one worth-while, given the benefits, I would think
Lloyd McKenzie (Jul 13 2017 at 17:10):
We don't use xlsx, we use the .xml Excel format. The problem is that the XML itself is volatile and not terribly merge friendly. It's possible but pretty evil and not something that's acceptable as part of regular day-to-day business. (It's often easier to reapply changes than to try to figure out how to merge.)
Sean McIlvenna (Jul 13 2017 at 17:59):
Ah. I see. Sounds like we need some better tooling to build resources and data types.
David Booth (Jul 13 2017 at 19:12):
Perhaps a github webhook could be used to canonicalize the .xml Excel when it is pushed, to avoid spurious differences caused by different committers using different tools. I like the idea of exploiting github as a collaboration platform.
Grahame Grieve (Jul 21 2017 at 10:55):
I already clone the data that matters out of the xml files into a merge friendly format that you can use to re-apply the changes manually.
Grahame Grieve (Jul 21 2017 at 10:56):
I tried to get the editors to consider migrating to a format like that one as their primary a long time ago but they are remarkably affixed to the spreadsheet- for good reasons
Grahame Grieve (Jul 21 2017 at 10:56):
for profiles, people should already be migrating away from using the spreadsheet formats
Grahame Grieve (Jul 21 2017 at 10:58):
the alternative work around for spreadsheets would be to right a custom xml processor that canonicalizes all the excel identifiers, so that you wouldn't see them when merging
Grahame Grieve (Jul 21 2017 at 10:58):
it's only because excel rewrites all the identifiers that we have this problem
Lloyd McKenzie (Jul 21 2017 at 20:11):
Excel does a bunch of things. It messes with styles. It captures what cell was selected on each tab, etc. It's probably possible to strip out (or normalize) the things that we don't need to be persisted across check-ins
Eric Haas (Jul 26 2017 at 20:52):
I'll pretend never GG said move away from excel for profiles.
Last updated: Apr 12 2022 at 19:14 UTC
