[WG: Sakai QA] [Management] 2.7.0 update: 12 Nov 2009 trunk freeze on new features (proposal)

Charles Hedrick hedrick at rutgers.edu
Wed Nov 11 11:58:38 PST 2009


We'd like to start testing as soon as there is a feature freeze,  
probably on the QA server. To do this, we need a few things:

1) A list of what is (or equivalent, what is not) covered by the  
feature freeze. It doesn't make sense for us to do QA on something  
that isnt frozen. Let me say that the most problematical part for us  
has been OSP. I would *really* like for it to be covered by the  
feature freeze.

2) Confirmation that we can put data on the QA servers and it won't  
get disturbed. To test OSP we have to upload a significant amount of  
data. if the database is regularly reset, it is essentially impossible  
for us to do useful QA.

Trying work back from our schedule: We need to deploy in May. In order  
to do local merges and then local QA and bug fixes, we probably have  
to start in February. My sense is that if we're going to get the  
project teams to fix things (i.e. so we don't have to do fixes  
ourselves) we pretty much have to start right now. It's going to take  
us a while to do a full QA cycle, and we have to assume that teams  
won't fix bugs instantly. Fixes developed after mid-February aren't as  
useful to us, because at that point we start our own integration. Once  
we start that process, we can't rely on community fixes, both because  
we can't be sure that the community will actually fix everything we  
care about by May, and because we have to check to see whether bugs  
are in our code or the community code.



On Nov 4, 2009, at 2:34 PM, Anthony Whyte wrote:

> Last week I polled project teams individually relative to my  
> proposal to move forward from the first week of December to 12  
> November 2009 a 2.7.0 new features freeze date.  The freeze date  
> would apply to Sakai trunk projects destined for 2.7.0 (e.g.,  
> announcements, assignments, chat, rwiki, etc.) that are not slated  
> for independent release.  The freeze date would also not apply to  
> projects under consideration by the product council for inclusion in  
> 2.7.0 (e.g., basiclti, profile2, sitestats, etc.), all of which are  
> slated for independent release as well.
>
> GOALS
>
> 1. establish project team consensus relative to a freeze date
> 2. accelerate, if possible, the creation of a 2.7.x branch
> 3. generate as soon as possible a 2.7.0-m01 milestone tag for  
> deployment to 2.7 QA servers at UvA, UCT and Marist (and hopefully  
> elsewhere)
> 4. get testable artifacts into the hands of QA now rather than later
>
> I plan to generate the 2.7.0-m01 milestone tag on 12 November and  
> thereafter generate follow up with milestone/alpha/beta/rc tags  
> every 7-10 days until 2.7.0 is released.   A freeze on i18n language  
> bundles would occur later (Beth Kirschner recommends mid-January  
> 2010).  Bug fixes can continue to flow from trunk into 2.7.x  
> unhindered until we decide that cutting a 2.7.0 release candidate is  
> warranted (i.e., alpha/beta tags indicate that the bug rate is  
> declining).  Thereafter bug fixes will be triaged (e.g., blockers,  
> critical fixes get priority).
>
> Projects teams planning independent releases will be encouraged to  
> begin producing stable releases of their code as soon as is possible  
> so that they can be included in the milestone releases of 2.7.0.
>
> It is anticipated that 2.7.0 will be released in the latter part of  
> Q1 2010, dependent as always on the elimination of blocker and  
> critical issues.  I recommend that as a Community we work to ensure  
> that 2.7.0 is released on time so that follow up maintenance  
> releases can occur between May-August in order to support deployers.
>
> POLL RESULTS
>
> +1.  So far no project team or lead has objected to my proposed  
> feature freeze date (tally below).  There are a few projects I have  
> not polled, none of which I believe have any feature changes that  
> impinge on 2.7.0.
>
>
> OBJECTIONS
>
> If anyone objects to a feature freeze on trunk code commencing 12  
> November 2009 please reply to the list stating your objections.   
> Otherwise, I plan to create the 2.7.x branch on 12 November 2009 and  
> generate a milestone tag.
>
> Cheers,
>
> Anth
>
> ____________________________________________
>
> 2.7 NEW FEATURE FREEZE DATE 12 NOV 2009 PROPOSAL
>
>  +1
>
> access (Eng, UMich)
> announcement (Prakash, Silver, UMich)
> assignment (Qian, UMich)
> 	intends to address SAK-17273 for 2.7
> calendar (Kirschner, UMich)
> calendar-summary (Fernandes, UFP)
> chat (Maurer, IU)
> config (Whyte, SF/UMich)
> content tool (Eng, Silver, UMich)
> dav (Hedrick, Rutgers)
> gradebook (Wagner, IU)
> 	commits planned to address SAK-15311 (but also see Gradebook 2 below)
> linktool (Hedrick, Rutgers)
> mailarchive (Jones, UMich)
> metaobj (Kirschner, Botimer, UMich)
> osp (Kirschner, Botimer, UMich)
> 	two sets of new osp features for 2.7: Collaborative portfolios and  
> IU Matrix enhancements
> podcasts (Thomas, Wagner, Wang, IU)
> portal (Speelmon, IU)
> postem (Wagner, IU)
> providers (Theriault, Columbia, McCallum, Unicon)
> 	commits planned to address SAK-10227 and possibly SAK-16816,  
> SAK-10025 for 2.7
> reset-pass (Horwitz, UCT)
> roster (Thomas, IU)
> 	 commits planned to address SAK-14743 and SAK-14744 for 2.7
> rwiki (Prakash, Silver, UMich)
> site-manage
> syllabus (Nguyen, Thomas, Wagner, Wang, IU)
> textarea (Ryan)
> velocity (Silver, UMich)
> was (Luong, IBM)
> webservices (Swinsburg)
> 	commits planned a few new webservices for 2.7
> usermembership (Fernanades, UFP)
>
>
> AWAITING REPLY
>
> admin tools: alias, authz, memory, tool, site, user
> blog (Fish) -- as I recall Adrian wanted to replace blog was a new  
> implementation
> citations (Smail, IU, Eng UMich)
> presence (Marquard, IU)
> web content (IU, UMich, etc.)
>
>
> NOT POLLED
>
> courier
> help
> jobscheduler
> jsf
> login
> mailtool (stealthed in 2.6)
> message
> presentation (stealthed in 2.6)
> profile
> reference
> reports
> rights
> sakai-mock
> samples
> taggable
> warehouse
>
>
> INDEPENDENT RELEASE CANDIDATES
> (not subject to 12 Nov freeze date)
>
> common (archive, common, edu-person, import, manager, privacy, type)
> edu-services (cm-service, gradebook-service, sections-service)
> content-review
> emailtemplateservice
> entitybroker
> msgcntr
> polls
> samigo
> search
>
> ADDITIONAL CAPABILITIES -- INCLUSION SUBJECT TO PC APPROVAL
> (not subject to 12 Nov freeze date)
>
> BasicLTI
> Conditional release
> Profile2/TinyURLService
> SiteStats
> Gradebook2 (the GB2 team would like to update the shared gradebook  
> data model so that schools who choose to run GB2 can run it without  
> recourse to patching)
> _______________________________________________
> management mailing list
> management at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to management-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20091111/aa40e732/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20091111/aa40e732/attachment-0001.bin 


More information about the sakai-qa mailing list