[Building Sakai] 2.7.0 update: 12 Nov 2009 trunk freeze on new features (proposal)
|
View:
New views
2 Messages
—
Rating Filter:
Alert me
|
 |
[Building Sakai] 2.7.0 update: 12 Nov 2009 trunk freeze on new features (proposal)
by Anthony Whyte
::
Rate this Message:
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) _______________________________________________ sakai-dev mailing list sakai-dev@... http://collab.sakaiproject.org/mailman/listinfo/sakai-dev TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe" |
|
|
Re: [Building Sakai] [Management] 2.7.0 update: 12 Nov 2009 trunk freeze on new features (proposal)
by Charles Hedrick
::
Rate this Message:
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:
_______________________________________________ sakai-dev mailing list sakai-dev@... http://collab.sakaiproject.org/mailman/listinfo/sakai-dev TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe" |
smime.p7s (3K) | Free embeddable forum powered by Nabble | Forum Help |
