[Building Sakai] 2.7 update

[David Horwitz]

Hi Clay

Thanks for the update I'd like to add 2 late breaking proposals from the
Branch managers, these emerged over the weekend as problems to
independent tool releases:

*Proposal 1: Move privacy to the commons project*
As a number of tools (including message centre) have dependencies on
privacy we propose moving this to the common project. As the common
project contains SakaiPerson, and type manager we feel this is a logical
place for it to go.

*Proposal 2: Separate Gradebook Service from tool*
Both message centre and Test & Quizzes have a dependency on the
Gradebook service. We also have a second implementation of the gradebook
(gradebook 2) that several schools have indicated they intend to run in
2.7. It seems sensible to:

1) Split the gradebook service from the tool implementation
2) Create a gradebook pmc to look after it drawn from the gradebook and
gradebook 2 teams
3)  Task the pmc to develop a unified service that supports both tools
(gb2 currently has some extensions to the existing service)

I would gladly undertake 1. The general idea was discussed at the
project planing meeting in Boston and as I recall was well received.

Regards

David

Clay Fenlason wrote:
> A fair bit of work and discussion has been happening around 2.7
> off-list and with particular project leads and teams, but it's
> important to represent these on-list and clarify a few points.
>
> It's beginning to look like the scope of 2.7 may be constrained more
> tightly by available QA resource than past releases. The fixes going
> into 2.6.x have been significant enough that QA for 2.6 maintenance
> releases is non-trivial, and they need to be a priority. At the same
> time resource is increasingly going toward Sakai 3 efforts, which is
> also well and good. As things stand, however, the upshot is that
> unless QA volunteers come forward in a strong way we may very well
> face a number of decision points where new capabilities will not be
> included in 2.7 because of a lack of people and time to test them
> adequately. I hope that's an exhortation and not just a frank
> appraisal.
>
> BRANCH MANAGERS
>
> We have three branch managers working together on various aspects of
> 2.7 right now. Anthony Whyte, David Horwitz (focussed on the msgcntr
> branch), and Steve Swinsburg. We're very grateful for their efforts.
>
> CODE FREEZE
>
> The beginning of a shift toward independent component releases has
> introduced some extra latitude in the schedule and coordination, but
> there still needs to be a general freeze point where the changes not
> included in an independent release are hardened into a 2.7.x branch
> (in the interim Anthony has prepared a snapshot of trunk that's being
> used as a QA branch for now). This freeze date and its negotiation are
> owned by QA, and Nov. 20 has been set as the target. Pete will be
> going directly to a few key players to pin down reasonable code vs.
> message bundle freezes, and I expect he will have more to say very
> soon.
>
> INDEPENDENT COMPONENT RELEASES
>
> We have now two big tools - the tools with the largest sets of planned
> changes for 2.7 - moving toward independent releases: Forums and Tests
> & Quizzes. Forums (or, more precisely, the msgcntr module) is the
> first to have all its changes completed and merged into a branch, the
> team from Michigan is putting finishing touches on the last remaining
> UI merges as we speak, and we should have it on a QA server running
> against a snapshot of trunk this week.
>
> Although part of the ambition is to have project leads take greater
> responsibility for seeing the changes they introduce tested and
> documented themselves, we know that some extra support is going to be
> called for until the new pattern is adjusted to, and so Foundation
> staff will be playing a strong supporting role for this first wave of
> tool releases.
>
> Independent releases are not governed by code freeze in the same way
> as other code changes, to the extent that they have already conducted
> their own QA on the road to being released in the first place. Our QA
> community may be able to work them into the rotation post-code-freeze
> on a case by case basis, but again, the arbiter of this process will
> be QA (with Pete as lead and point of contact).
>
> NEW TOOLS / CAPABILITIES
>
> This is something that I think hasn't been spelled out in the past, so
> I'll venture it tentatively, but I think that new Sakai 2 tools and
> capabilities that have worked their way through the product
> development process should essentially be treated like independent
> component releases as described above, as far as QA and release
> planning goes. By the time they come through the product development
> process they will - as the process has been defined - be ready for
> release and maintenance.
>
> So if you have a new component or tool (or even a very mature contrib
> tool), for example, and you want to be in 2.7, the path begins with
> incubation and the Product Council. [1]
>
> POST-2.7
>
> I expect there will be a number of independent releases of tools
> tested against 2.7 but not included in the general release, most often
> because QA couldn't work them into the schedule with available
> resource. Yet these component releases will be relatively easy to add
> to a base 2.7 as a technical matter. In fact, I expect release
> documentation to highlight and link to some of these, as extra
> components a deployer may want to bundle in.  So testing and
> documenting independent releases will be put to good effect, even in
> cases where tools had to be left out of the general release.
>
> We are not assuming that there will be a 2.8 at this point. One
> possible future is that the 2-series plays out the remainder of its
> lifecycle in the form of additional component releases tested against
> a stable 2.7.x. We'll see how things go, and how the community moves
> over the course of the next year.
>
> Corrections, comments and questions welcome as always.
>
> ~Clay
>
> [1] http://confluence.sakaiproject.org//x/sgTtAw
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090929/076b0850/attachment.html