[Portfolio] Clarification: possible OSP independent release
A.M.Berg at uva.nl
Tue Jun 29 13:36:15 PDT 2010
If we change the game, then we change it for the QA servers as well. If I have an out of main cycle plan for OSP which saves QA stress at peak load then I will be happy to actively search for a QA admin/server to support and will even think in terms of allowing you to automatically update a QA server and restart it. I would first do this by hand and then do that through Hudson and look at populating the maven repository and run automatic tests at the same time. It just requires a little imagination and a bit of effort from central QA.
QA Director - The Sakai Foundation
Senior Developer / Quality Assurance
Group Education and Research Services
Central Computer Services
University of Amsterdam
From: Beth Kirschner [mailto:bkirschn at umich.edu]
Sent: Tue 29-6-2010 16:03
To: Anthony Whyte; Berg, Alan
Cc: osp List
Subject: Re: [Portfolio] Clarification: possible OSP independent release
Anthony & Alan,
One possible reason _not_ to move OSP to an independent release
cycle is the distributed nature of the QA team. QA is usually done by
folks at different institutions, who need one central, stable QA
server with a release candidate to test with. The nightly servers are
generally not appropriate, since their databases are wiped with every
build. We're currently without the resources for a dedicated OSP
server, so I wonder if you have any suggestions on how we might handle
QA for an independent OSP release?
On Jun 28, 2010, at 2:03 PM, Anthony Whyte 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.
> 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
>> 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
>> 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"
> portfolio mailing list
> portfolio at collab.sakaiproject.org
> TO UNSUBSCRIBE: send email to portfolio-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the portfolio