[Building Sakai] 2.7 update

[csev]

I am kind of outside this whole process so if my comments make no  
sense - that is why.

I generally like these proposals - with comments inline.

On Sep 29, 2009, at 8:06 AM, David Horwitz wrote:

> 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.

This is fine as long as the only thing that is happening is source  
moves and artifact renaming.   I would suggest *not* changing package  
names or API signatures for the moved code until after 2.7 - this way,  
if patches need to move backwards or forwards, the only thing that  
changes is where the patch goes in the source tree (at least for 2.7).

Lets not make API changes simply to make package names "prettier".

> 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 like this as well - similar to the above constraints.  Limit the 2.7  
changes to moving things into independent locations.   I personally  
would keep the GB2 changes away from trunk in 2.7 with one  
exception.   We have in the past made 100% upwards compatible  
extensions to a trunk API to make it easier to drop in new stuff in a  
branch.   The impls for the new signatures can and should throw "not  
implemented" in trunk - since GB1 does not call these - this is not a  
problem for GB1.   It does make having the GB2 service mods much  
easier to live in a branch for a while.

We did this for portal/hierarchy and transformable and it worked  
nicely.  We knew we would not get impls in time - but we extended the  
API (2.4 I think) and stubbed things out so that development and  
deployment of these features could be done as a nice seamless  
extension overlay.

This way we don't have any new functionality to QA - we just need to  
verify that the code move did not introduce any problems.  And then in  
2.8 the code slides in without disturbing source layout or API.  I do  
like to split risk over two releases if possible. :)

An assumption of all of the above is that GB2 is *not* in trunk for  
2.7.  2.7 prepares the trunk for GB2 and makes it much easier for  
sites who chose to run GB2 - but we do not make that move (keeping QA  
load down for 2.7).

For your points (2) and (3) - it would seem that the pmc you mention  
is the GB2 folks.  If the GB2 folks are not willing to own the  
combined GB service - that would be a warning sign to us w.r.t. GB2.   
If the GB2 folks are not willing to keep GB1 working for at least two  
releases after GB2 is in trunk, then GB2 should not come into trunk  
IMHO and just continue as contrib.

I do not look favorably at folks who want to be in trunk - who  
deprecate or break existing functionality the moment their code is  
accepted and included.  We need to stabilize the 2.x processes so that  
resources can flow to 3.x.  Part of that is slowing things down and  
making "not breaking existing functionality" an important guideline  
for any technical decision we make.

/Chuck

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090929/fa1d0bcc/attachment.html