Stream: fmg
Topic: Pipelining releases
Josh Mandel (Jun 05 2020 at 16:50):
@Lloyd McKenzie have you thought about what it would take to have a pipelined release process where, at intervals, ballots are focused on specific subsets of content that are identified as additions in a given cycle? Is it really the case that the whole spec needs to undergo ballot review in every release?
Lloyd McKenzie (Jun 05 2020 at 16:59):
The whole spec doesn't have to undergo ballot, BUT anything that doesn't undergo ballot can't change except for technical corrections. What that means is that we'd have to have really tight control over whether/when approved change requests are applied to the spec. It would also make the CI build much less useful because we wouldn't be able to apply changes until there was agreement that resource/page-set was in the scope for an official ballot or release. Because we use spreadsheets for authoring profiles - and because of widespread dependencies in terms of descriptions, guidance in related resources, choosing to migrate certain pull requests to an official publication and withholding others isn't likely very practical. (And it would require much more rigor in the pull request process than we currently have, or that is likely achievable with the volunteer team we have who makes the changes.)
Josh Mandel (Jun 05 2020 at 18:36):
Basically though that just pushes us towards feature branches rather than merging everything into one master branch before it's ready. We could still have a functioning continuous integration system to support us in this.
Lloyd McKenzie (Jun 05 2020 at 18:55):
Yes, we could do the following:
- figure out an alternative way of authoring resources that is much more source-control friendly while still being relatively maintainable by the content authors we have now (will require some degree of tooling investment, though how much depends somewhat on the tool)
- come up with a policy for the use of feature branches rather than just pull requests against master and figure out a mechanism for performing appropriate oversight of that (will require personnel resources)
- come up with a governance process that allows us to determine what subset of features is appropriate for smaller, more frequent ballots and publications
However, we still have the problem that while there are small communities that want 'faster' publications with 'their' content, the community at large tends to want longer gaps between releases so they can keep up and they can minimize the number of conversion interfaces and maximize the likelihood that the partners they want to communicate with will support the same version they do. So, given that, is it worth the investment to change our release process?
John Moehrke (Jun 05 2020 at 19:33):
I think the subsetting would be a workable solution, where as feature branches might be a method of doing that. I understood that we were heading toward a core set with domain specific subsets eventually. Seems the medication product space is clearly not as core to everyone else is it is to them. Similar could be said of financial management, or genomics, or etc... I think the hard part of subsetting is that a subset must be manageable on their own timeline, but it must integrate seamlessly with the core and require no deviations from the core without core version control. Thus yes the core still needs to continue to tick along as a body, but subsets can happen asynchronously. Essentially a subset is similar to an IG, except that it can create and manage resources known to the core, that is to say the core knows of the resource but doesn't know anything more than the basic resource pattern.
Lloyd McKenzie (Jun 05 2020 at 19:37):
We can't publish subsets independently. There's one schema per release. That's a foundational pillar of FHIR. We can publish IGs as we wish, but all resources have to be in a single release. We can publish core releases where only some things change, but we can't publish core releases that only contain some things.
Lloyd McKenzie (Jun 05 2020 at 19:38):
(Note that schema = reference implementation = test server = much other key infrastructure)
Last updated: Apr 12 2022 at 19:14 UTC
