[Portfolio] Clarification: possible OSP independent release

[Noah Botimer]

Fellow OSP contributors and adopters,

There has been some confusion in the community about the possibility of putting OSP on an "independent release" cycle. This message seeks to clarify what this might mean for us and to allay some of the concerns raised.

First, and most importantly, the notion of an independent release is completely separate from a project's standing ("contrib", "core", etc.). It is a designation that means two things:

	1. These "indie projects" are able to package and release changes between versions of the Sakai community release.
	2. These projects are updated to a specific technical configuration that facilitates these independent releases by the project teams.

In terms of how these relate to the Sakai community releases (e.g. 2.7.0, 2.6.3), what happens is that the project teams designate the latest desired and compatible version to be bundled. This is one way to add some predictability to the contents of a given community release version as more direction rests with the project teams.

Something this provides for adopters is the ability to upgrade their installed version of an independently released project with more confidence. Rather than waiting for a maintenance release, an institution might install an update to a specific tool or project in advance. In some cases, this is anticipated to offer early access to features that would conflict with the policy of maintenance releases only including bug fixes. In others, this might mean earlier general availability of fixes for important issues.

For those who are more technical, this contrasts with "running the x branch", such as 2.6.x, to acquire these fixes between maintenance releases, or "running trunk" to access new features scheduled for a future major community release.

Another important benefit of reconsidering how the community release is assembled is around quality assurance. For example, if a set of issues is addressed and the OSP group decides to release a new version, a defined QA effort can begin without needing synchronization with the rest of the community release.

The other most important item to note is that the notion of OSP being an independent release is a suggestion, not a decision made. The benefits of this setup and what it would take to reconfigure and release OSP like this can be discussed on a future weekly call. For that, the community Release Manager and/or QA Director should be present to provide accurate answers to questions raised.

As a brief aside, I do think that it is worth noting that the practices of the OSP group are positive examples in the community. Our weekly calls of majority non-technical particpants, our commitment to describing systematically and reviewing the features and changes we propose, and our dedication to maintaining test plans and documentation are all standouts in the Sakai community. I believe that we have been modeling good behaviors for some time and that it is important to recognize the hard work of discipline and consensus building within a truly community-owned project.

I hope that this provides a better starting point for the conversation and that we can form a collective, considered opinion of whether this model is right for OSP. I look forward to the discussion.

Thank you,
-Noah Botimer