OpenSolaris: Restricted builds through the ages
Last month, Stephen Harpster announced that there would be a two-build sequence with restricted integration conditions. This sort of restriction isn’t new for Solaris development, as I’ll show below, but the means of arriving at the restriction and the manner in which we shared it shows we are still learning what an “open process” must do—and when we miss, to make sure we learn from those mistakes.
So Stephen’s announcement noted that Build 54 and 55 would be “only bug fixes”. That’s not new; we can look at the build-by-build restrictions on ON integrations for Solaris 8
Solaris 9,
and Solaris 10,
Here, each box represents a cycle of the two-week build clock. Solid boxes indicate a strong “bugfix only” integration policy (like “stopper only” or integrations requiring the consolidation’s technical lead’s approval); outlined boxes indicate a weak “bugfix only” integration policy (meaning no specially approved projects). I’ve worked out these integration policy digests from the ON schedules of past releases; policies will vary for other consolidations, but should match up roughly with ON’s history.
Solaris 8 and 9 show the classic “(Development Complete–)Beta–Beta Refresh–Ship” pattern that characterized Solaris releases. In Solaris 10, the Solaris Express program gets reflected in that, although there were identified Beta and Beta Refresh builds, the shift from early release to late release really takes place with the Beta Refresh build, which was the first in a series of restricted builds, until Ship.
Thus, for current Nevada, ON looks a lot like it did for the release that became Solaris 10:
Inferences you might make are at your own risk.
Of course, the freezes we took in the past were easily achieved as there was only one distribution derived from the ON sources. Now that we are a community with a collection of active distributions, the notion of periodic and public restricted builds may still be attractive, so that distributions could choose to issue their latest version from a known stabilized build. Certainly current distributions (or emerging ones) might consider using the stabilized build 55—however we got here—as an opportune version to base their next release upon.
Of course, there is a tradeoff between letting each distribution stabilize and a consolidation-wide restriction. Perhaps a topic for a future post?
We, as a community, will need to have a position on restricted builds. Please think about it, and then feel free to comment here, and mail me privately. Public discussions, I suspect, are more valuable: opensolaris-code would be a good forum for the technical tradeoffs, possible frequency of stabilized builds, and so on, while cab-discuss would be the best place for inter-distribution and coordination issues.