[Portfolio] Clarification: possible OSP independent release

Mon Jun 28 11:39:41 PDT 2010

So, it sounds to me like a good proposal...particularly for the
smaller tools, which can iterate quickly and can make mad progress
fast with this process. The testing process for a small tool is
presumably easier than for a "complex" suite of tools like OSP.

We have always struggled with the QA issue in OSP. Oddly, more of the
OSP community is qualified to QA the OSP tools than build them, but I
feel we are still constrained by our willingness/inability to commit
to the rather daunting task of testing all of OSP for the big
community releases. OSP testing seems to take a lot of setup time, has
a steep learning curve, involves multiple tools, many configurations
to test, few automated processes... yada, yada, yada...

This proposal of possible multiple "releases" of OSP could be a big QA
burden if we needed to run through all the tests to discover
regressions. If that happened, I think this might be a tough row to
hoe. We probably wouldn't be much faster than we are now!

Alternatively, if the focused nature of the indie release cycle allow
us to limit the scope of development to a small set of
features/bugs/enhancements, and required QA testers to target just
those issues, perhaps we could get more people to commit to the
smaller QA bursts. This probably would mean exposing ourselves to the
possibility of regressions between "community releases" (when full
tests would need to be run) if the testing chosen wasn't sufficient,
but then again...we get some of that now.

As someone who has repeatedly committed QA time on the wiki and then
found myself under-delivering under the weight of the task, I think
that this process could keep the scope of incremental QA testing
doable. Perhaps others would also be more inclined to participate
under these terms?

Unfortunately, it still doesn't address the larger (full testing) QA
issue that would periodically need to happen to prepare for the
community release.

Sean Keesler
130 Academy Street
Manlius, NY 13104
315-682-0830
sean.keesler at threecanoes.com

On Mon, Jun 28, 2010 at 2:03 PM, Anthony Whyte <arwhyte at umich.edu> wrote:
> 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.
>
> Cheers,
>
> Anth
>
>
> 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
>> http://collab.sakaiproject.org/mailman/listinfo/portfolio
>>
>> TO UNSUBSCRIBE: send email to portfolio-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>
>>
>
> _______________________________________________
> portfolio mailing list
> portfolio at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/portfolio
>
> TO UNSUBSCRIBE: send email to portfolio-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>