[WG: Sakai QA] proceeding - Sakai 2.10 schedule

Thu Oct 17 10:34:59 PDT 2013

[dev, qa and cle release]

Hi All,

This is a status update, and also a continuing call for updates and input. 

It looks like the target dates for a 2.10 release is firming up. There is still some discussion on the PMC list (sakai-pmc at collab.sakaiproject.org. Formerly the TCC) about increasing the scope a bit and moving the timeline out a couple of months. I presume that discussion will move to the Dev list, plus other lists, if it gains traction. In the meantime, I think we need to proceed on the basis of the 2.10 schedule as-is for our targets (because if we don't then we are likely to miss our targets!). I would like to expand this discussion to other lists, but would prefer for the PMC to tie off on the scope question first. My 2 cents.

[Please remember that these are just target dates, not certainties. As we go through the various phases we should have a better idea of how realistic our schedule is.]

2.10 Target Schedule
-------------------------------
2013 mid-Oct  - Scope Freeze (about now….)
2013 mid-Nov (pre-Thanksgiving)  - Branch cut - Alpha 01
2014 early-February - Beta 01 - criteria - no blockers; string freeze; scope implementation freeze (in case we decide some scope items can be completed during Alpha.)
2014  early- April  - RC 01
2014 mid-May - GA (General Availability aka production)

Action for YOU
---------------------
If you added a link to a Jira with a patch, proposed to be in 2.10, to https://jira.sakaiproject.org/browse/SAK-24197 - since October 4 , please let me know. We reviewed all the Jiras linked before that date.

Scope items - need to lock these down ASAP
------------------------------------------------------------------
* Keep in mind that everything which has already been merged into trunk IS in scope. These are additional potential items. 
* We need to identify everything that is going to get done and who is going to be doing it, and (for the most part) get it all done, before Alpha 01.  Any exceptions (i.e. items agreed to but may not be completed in time for Alpha) need to be agreed on and noted (planned). 

a) Mixed content HTTP with HTTPS -  Is this in scope for 2.10?  I see some tickets like this, but curious if we are comprehesively covering this one. Example ticket - https://jira.sakaiproject.org/browse/SAK-23850

b) Link tool - decommission proposal - see http://collab.sakaiproject.org/pipermail/sakai-dev/2013-October/024844.html - Anthony Whyte

c) Yale Signup tool - current plan is to get this committed to trunk. Any objections/concerns?  Does this need a property to be turned off by default in 2.10? - AZ is helping with this. 

d) Roster 2 tool to replace Roster - status? 

e) Spring Annotations - Not hearing any objections to this one. If a Jira ticket is opened , assign to Aaron Zeckoski (volunteer to work on this)

f) Portal chat on by default - I'm hearing two objections on this one - 1) performance problems identified by UMich not addressed; 2) Security issue for Test and Quizzes (no way to turn chat off for a test).  At the moment, if the concerns are not addressed, this looks like it will remain OFF by default. Is anyone using Chat in production?
Review Portal chat performance: https://jira.sakaiproject.org/browse/SAK-22286
Remove chat from some sites/tools: https://jira.sakaiproject.org/browse/SAK-23258

g) News feed tool to replace the News tool?  or Steve Swinsburg offered his portlet as a replacement - https://wiki.jasig.org/display/PLT/Simple+RSS+Portlet .  Not hearing anyone stepping up to get the News feed tool updated, so it looks either like we should stick with the existing News tool or look into Steve's offer for his RSS portlet. What is the next step? Who will take this one? If we cannot come to a decision soon, the existing News feed will probably stay for 2.10

h) Retire Profile for Profile 2 - is Profile already retired? - status? Is anybody working on this?

Scope Change Control
--------------------------------------
"New" idea. Well actually new terminology for something that I think has been part of Sakai oversight.

The big idea behind Change Control is that plans change, so let's have an orderly way to manage them. My perception has been that the PMC (formerly TCC) has acted as a "Change Control Board" in the past. I just want to confirm that for the 2.10 release the PMC will function in this way, and if not, then how do we cover this important function? For example, when AntiSamy was introduced in CLE 2.9.2 and turned on by default in 2.9.3 , that was a TCC decision because it was a new feature added into a maintenance release. Even though 2.10 is a new release, not a maintenance release, suggested changes can still emerge. So is this roughly how things will continue to be managed?

Thanks,
Neal

Neal Caidin
Sakai CLE Community Coordinator
neal.caidin at apereo.org
Skype: nealkdin
Twitter: ncaidin

On Oct 14, 2013, at 10:54 AM, Neal Caidin <neal.caidin at apereo.org> wrote:

> [sakai-dev and cle-release and sakai-qa]
> 
> Hi All,
> 
> Your Input
> -----------------------
> Please feel free to chime in with your opinion and especially if you think this is a good schedule or you have concerns about this schedule, definitions, etc.. Your input is welcome and appreciated. Please copy all the lists in your response? It helps maintain continuity in the discussion.
> 
> 
> Background
> -----------------------
> There has been some initial conversation with the CLE release team (aka Sakai team) and the PMC (previously known as TCC) about the 2.10 schedule. It does seem like there is significant initial support for this schedule.
> 
> First note: The final name for the release has not been determined. For convenience we are calling it the 2.10 release for now, but it could change to something like Sakai 4. Just a heads up.
> 
> When the branch is created for 2.10, it will be an Alpha release. Some recent discussion has been focused on determining the criteria to move from an Alpha release to a Beta release. 
> 
> Here is the latest schedule which I'm suggesting. For those who've been following, I've changed the Branch cut date from late-November to mid-November, just to emphasize we need to get Alpha cut before (American) Thanksgiving but essentially unchanged.
> 
> 
> Proposed Schedule for Target milestones - Sakai 2.10
> -------------------------------------------------------------------------------
> 2013 mid-Oct  - Scope Freeze (about now….)
> 2013 mid-Nov (pre-Thanksgiving)  - Branch cut - Alpha 01
> 2014 early-February - Beta 01 - criteria - no blockers
> 2014  early- April  - RC 01
> 2014 mid-May - GA (General Availability aka production)
> 
> 
> QA Assumptions
> -------------------------------
> * Sufficient level of QA testers / testing available between phases.
> * Anticipate the greatest need of QA testing to be from Beta 01 (February 2014) through release (May 2014) … [doesn't mean we don't need QA testing once Alpha is cut. We do!]
> * Will need people to update Regression scripts to include new features
> * Will need both Jira testing and Regression testing, but a lot more focus on Regression! Ad hoc testing will be welcome (i.e. test features that are important to your institution using your own methodology and report back to QA lead. The more approaches and more eyes we get on the release the better).
> * Having some "synchronized testing" in which we will schedule time to test together as a community, will be scheduled. 
> 
> 
> Proposed Definitions
> ---------------------------------
> 
> Scope Freeze - all the scope for the release identified. In all but rare cases, the items identified for inclusion in the release should also be resolved and fixed (Jira terminology) before the Alpha release is cut. 
> 
> Alpha - scope freeze defined, branch cut, blocker bugs fixed. It is possible that new features could be added, BUT these features need to be defined in the Scope freeze, and we should decide explicitly which features should go in during Alpha phase. The default position is a feature which is not resolved/fixed before Alpha is NOT in the release. Final strings (button text, instructions, labels, etc.) defined during Alpha. String freeze before Beta.
> 
> Beta cut - moderate level of Alpha testing completed. Not only scope freeze and implementation freeze for new features before cutting Beta. No new features added during Beta. String translation occurs during Beta. Does this mean that Online Help text is also frozen when we cut Beta (that seems ambitious)?
> 
> Release Candidate - All blocker and critical bugs fixed from Beta phase. Release candidate means the release is close to ready for release (aka general availability). At this phase, we only hold up moving to GA if blocker bugs are found. What constitutes a blocker bug is implicitly held to a higher level of impact to the release (stack traces, gradebook calculation errors, etc. )
> 
> GA - general availability of the release (aka production).  Tag is created. Final immutable release. 
> 
> 
> Included in Scope so far:
> ---------------------------------------
> 1) Here are a list of proposed Patches for 2.10. A number have already been merged:
> https://jira.sakaiproject.org/browse/SAK-24197
> 
> 2) Anything merged into trunk to-date (which means we may need to be more conscious and thoughtful about additional merges in trunk between now and Alpha so as not to increase the scope)
> 
> 
> Open questions about Scope? 
> ------------------------------------------------
> The PMC (formerly TCC) has a page with a number of items that had been under consideration for 2.9/2.10.  https://confluence.sakaiproject.org/display/TCC/TCC+CLE+Action+Items
> 
> From this several discussions have emerged, mostly on the sakai2-tcc list, some on the sakai-pmc list, and sometimes the cle-release-team list (sorry for the inconsistency, sakai-pmc is the latest, but a lot of conversation occurred while PMC was still TCC). We should target THIS WEEK to make a decision, if at all possible.
> 
> I am not clear on the status of most of these items personally. Feel free to take a look at the list archives and see what you think. 
> 
> a) Link tool -  may be a proposal to decommission the Link tool soon? LTI addresses many of the use cases that Link tool used to handle?
> 
> b) Yale Signup tool -  I think the main concern is support if we bring this tool in? Does it fall to the CLE release team or is there another way to support? That's what I was hearing. There is a lot of positive community interest in the Yale sign up tool (#1 used Contrib tool based on the Sakai Tool survey earlier this year). 
> 
> c) Roster 2 tool to replace Roster 1?  I'm not clear on status. Sounded like there was not clear consensus to me.
> 
> d) Spring Annotations - to me, I think I saw positive feedback on this one and no objections/concerns. 
> 
> e) Portal chat on by default - not a clear outcome. I saw concerns about performance if Portal chat was on by default, but a challenge to that concern, saying there is no evidence of performance issues for portal chat.  ?
> 
> f) News feed tool to replace the News tool?  Nobody has stepped up to fix the News feed tool to get it in shape. Sounds like it is a better tool than the News tool and over time, probably about the same level of maintenance (I'm personally not familiar with differences). Steve Swinsburg offered his portlet as a replacement - https://wiki.jasig.org/display/PLT/Simple+RSS+Portlet
> 
> g) Retire Profile for Profile 2 - Mostly Profile 2 is the main tool but Profile still exists due to dependencies? 
> 
> Thanks for your help!
> 
> Check September and October archives for discussions
> -----------------------------------------------------------------------------------
> 
> http://collab.sakaiproject.org/pipermail/sakai2-tcc/   
> 
> http://collab.sakaiproject.org/pipermail/sakai-pmc/
> 
> 
> Cheers,
> Neal
> 
> 
> 
> Neal Caidin
> Sakai CLE Community Coordinator
> neal.caidin at apereo.org
> Skype: nealkdin
> Twitter: ncaidin
> 
> 
> 
> 
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20131017/23942162/attachment-0001.html 