[Portfolio] Clarification: possible OSP independent release
arwhyte at umich.edu
Mon Jun 28 11:03:51 PDT 2010
I'd enjoy providing an overview of how the "indie" process works in an upcoming portofilos call. The overarching goal is to better align our release practices with the natural production rhythms exhibited by the various teams who produce code for Sakai. The monolithic nature of much of Sakai's current release practices together with the long lead times required in order to produce .0 and maintenance releases hampers our ability to deliver fixes and new capabilities in a timely manner. Sure, deployers can pick up fixes from the maintenance branch or troll trunk for new changes but both exercises requires an insider's knowledge that adds yet another barrier to entry.
Repackaging the portfolios project in order to enable us to generate stable versioned tags and release binaries on an "off-cycle" basis injects flexibility into the release management process. If you have a set of fixes ready to be pushed to the Sakai Community days or weeks in advance of the next Sakai maintenance release you don't need to wait for the monolithic release process to catch up, you release when ready; if you have new capabilities ready for release you do not need to wait months for the next Sakai .0 release to get them out to your users; again you release when ready.
A case in point. Sakai 2.7.0 deploys basiclti-1.1.3. A couple weeks ago, I released basiclti-1.2.0 in order to provide a set of additional capabilities that Lance Speelmon wrote in support of Sakai 3. The fully automated release took less than 3 minutes to accomplish and the release binaries were picked up Ian Boston soon after. Fast, efficient, flexible.
Currently 17 Sakai projects are now handled as indie releases; the kernel of course, but also projects like basiclti, message center, profile2, samigo, sitestats and search. The release process itself is fully automated, pom versions in affected branches are updated automatically, binary artifacts are uploaded automatically, conventions are enforced, etc. The process has known patterns, it's documented, it has a community behind it (e.g., Apache Maven) and a growing number of Sakai Community members who can perform the releases. Once set up, you will find the actual generation of a portfolios release a trivial exercise.
Looking forward to discussing the proposal in greater detail.
On Jun 28, 2010, at 10:57 AM, Noah Botimer wrote:
> 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
> portfolio mailing list
> portfolio at collab.sakaiproject.org
> TO UNSUBSCRIBE: send email to portfolio-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
More information about the portfolio