[sakai2-tcc] [Building Sakai] [Management] Sakai 2.8 Release Activity Schedule

[Speelmon, Lance Day]

FYI:

Begin forwarded message:

Date: September 17, 2010 12:04:10 PM EDT
To: <mt at collab.sakaiproject.org<mailto:mt at collab.sakaiproject.org>>
Cc: Megan May <mmmay at INDIANA.EDU<mailto:mmmay at INDIANA.EDU>>, Seth Theriault <slt at columbia.edu<mailto:slt at columbia.edu>>
Subject: Fwd: [Management] [Building Sakai] Sakai 2.8 Release Activity Schedule

Dear MT,

I would like to land some changes for hybrid in 2.8.  These are all low risk (i.e. off by default) loose integration points for integrating Sakai 2 and 3.  It would be ideal if these were included in Sakai 2.8 to ease adoption of hybrid in the near future.  Specifically:

1) providers: http://jira.sakaiproject.org/browse/SAK-17222
<http://jira.sakaiproject.org/browse/SAK-17222>1.1) Clean patch attached to JIRA ticket. patch<http://jira.sakaiproject.org/secure/attachment/21876/SAK-17222+2.8.patch>
1.2) OFF by default.
1.3) Adds the following new sakai.properties settings:
    // The nakamura user that has permissions to GET /var/cluster/user.cookie.json
  org.sakaiproject.provider.user.NakamuraUserDirectoryProvider.principal
    // The hostname we will use to lookup the sharedSecret for access to validateUrl
  org.sakaiproject.provider.user.NakamuraUserDirectoryProvider.hostname
    // The Nakamura RESTful service to validate authenticated users
  org.sakaiproject.provider.user.NakamuraUserDirectoryProvider.validateUrl
1.4) Adds the following new dependencies:
  org.apache.httpcomponents.httpclient 4.0.1
  net.sf.json-lib 2.3-jdk15
  org.sakaiproject.sakai-hybrid-util 1.0-SNAPSHOT (needs a release artifact)
  org.sakaiproject.nakamura.utils [0.5,)

2) login: http://jira.sakaiproject.org/browse/SAK-17223
2.1) Clean patch attached to JIRA ticket. patch<http://jira.sakaiproject.org/secure/attachment/21877/SAK-17223+2.8.patch>
2.2) OFF by default.
2.3) Adds the following new sakai.properties settings:
    // Disabled by default
  org.sakaiproject.login.filter.NakamuraAuthenticationFilter.enabled
    // The nakamura user that has permissions to GET /var/cluster/user.cookie.json
  org.sakaiproject.login.filter.NakamuraAuthenticationFilter.principal
    // The hostname we will use to lookup the sharedSecret for access to validateUrl
  org.sakaiproject.provider.user.NakamuraUserDirectoryProvider.hostname
    // The Nakamura RESTful service to validate authenticated users
  org.sakaiproject.provider.user.NakamuraUserDirectoryProvider.validateUrl
2.4) Adds the following new dependencies:
  org.apache.httpcomponents.httpclient 4.0.1
  net.sf.json-lib 2.3-jdk15
  org.sakaiproject.sakai-hybrid-util 1.0-SNAPSHOT (needs a release artifact)
  org.sakaiproject.nakamura.utils [0.5,)

3) hybrid: http://github.com/sakaiproject/nakamura/tree/master/hybrid/
3.1) Indie release - needs a maven maven's help to release an artifact into the sakai repo.
3.2) Provides two REST endpoints for Sakai 2. Both servlets are filtered by TrustedLoginFilter (i.e. x-sakai-token<http://sakaiproject.org/blogs/lancespeelmon/x-sakai-token-authentication>) and execute in the context of the current user.
  A) /sakai-hybrid/sites
     200 OK
  B) /sakai-hybrid/site?siteId=1234 OR /sakai-hybrid/site?siteId=1234?writeEvent=true
     200 OK; 400 bad siteId passed; 403 permission exception; 404 siteId not found

Thanks! Lance

Lance Speelmon
Scholarly Technologist



On Sep 2, 2010, at 8:43 AM, csev wrote:

Alan B,

I really don't think this will be much of a problem at all and it is perfectly correct for the S3 folks to be managing the hybrid progress in terms of overall timing, QA, etc.

We don't need to go into the S3 timescales in great detail here unless something in S3 wants a change in the 2.x schedule - like delaying 2.8 freeze for a few months to meet a S3 goal (which has not been proposed - just as an example).

Lance has done a great job expressing to the 2.x community what he needs and he uses 2.x words to express it - we in the 2.x community can keep our world relatively simple and focus on 2.x.   Lance has his feet both places and aligns things to fit into 2.x with a minimum of fuss.  You now also have feet in both places.

If during the 2.8 QA period there is some S3 QA testing of hybrid mode that identifies needed changes to the S2 hybrid bits and we are still making changes to 2.8 in general - Lance will make those changes/fix those bugs and things will work perfectly.   If issues are identified in S3's testing after 2.8 is released - then it can go into trunk and 2-8-x and later 2.8.1, etc releases.

The BasicLTI provider in 2.7 gave us a perfect example of how well this can work with a minimum of fuss.  I wrote the first version mostly as a turned off demo in 2.7.  Lance got interested as part of his hybrid mode strategy and started pushing it forward.  Since it was turned off in 2.7 - we gave Lance a lot of leeway in what he did to the provider and when he did it.  And that worked really well both during the release prep and in the 2-7-x branch after release.

The key to this is the beautiful "off by default" exemption which we should not abuse - but it applies perfectly to this case.  It avoids having hard alignment points when there is really no need to have hard alignment points.

/Chuck

On Sep 2, 2010, at 3:02 AM, Berg, Alan wrote:

Hi,

Firstly i recognise that the TCC is responsible for shepherding  2.X  and Hybrid mode is instigated in the Sakai 3 project structure, however qua technology it has feet in both 2 and 3. . I think you read the situation correctly qua impact for 2.8, the functionality is turned off by default.  Qua impact for central  testing resources we have to look at the wider picture of the timeline of the hybrid mode and bug fixing in three places Saka 2.x, Sakai 3 and directly by Lance with the gluing. I discussed this with Lance yesterday and promised to send an email to the TCC and Alan Marks, but you beat me to the punch.

There are two versions of hybrid promised Basic and Complete. The complete version has not been documented qua functionality but needs to be ready at the end of Q2 of the Sakai 3 project plan by June 2011.

The rough timeline for testing should look similar to: Sakai 2.8 goes from alpha to beta. Hybrid mode is tested against the beta and  bugs are pushed back to Sakai 2.x and Sakai 3 and the responsible party for the glue. The cycle is kept in check with the 2 week tagging cycle of the beta's. Testing needs to include functional testing, security, UI consistency, performance. Central QA needs to know what the landing time for the complete mode and actuate the cycle again. The testing resources need to be found from the community. I would expect those testers to come for the Sakai 3 project, but that is not clear as we have a general lack of resources. The bug fixes for at least the basic mode will need to be in step with the release of 2.8. Bug fixes associated with UI consistency may need to be negotiated as they have no immediate value for 2..8 or Sakai 3. The impact for Lance is that he will need good test plans for the full hybrid functionality and no doubt he will need to be quick with his programming fingers.

Alan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20100917/82b65c41/attachment-0001.html