2.5 Release Planning-20 (20080214)

Owned by Former user (Deleted)
Last updated: Feb 14, 2008 by Former user (Deleted)Version comment
8 min read

Attendees

If you know you will be attending, please list your name

  • Megan May (Meeting facilitator)
  • Peter Knoop (Sakai project coordinator & regular attendee)
  • James Logan (regular attendee)
  • Renu  (regular attendee)
  • David Haines (regular attendee)
  • David Horwitz_(regular attendee)_
  • Linda Place (regular attendee)
  • Anthony Whyte (Sakai community liason)
  • Jean-François Lévêque
  • John F. Hall
  • Charlie Shelton
  • Seth Theriault (semi-regular attendee)
  • Ian Boston
  • Jim Eng

Meeting Agenda

Background on Discussion Points

 Update From Cape Town

Content Conversion Utility

Moving from 2.4 to 2.5 requires adding several columns to the database tables used by the Content Hosting Service (the service used by the Resources tool, Dropbox, filepicker and webDav).  The conversion scripts contain DDL statements to accomplish those changes. The new columns enable a switch from XML serialization to "binary-entity" serialization, which is faster and requires less memory.  They also enable improved performance of quota calculations.  A conversion utility is provided in 2.5.x to insert values in these new columns.  You can get the benefits of binary-entity serialization without running the conversion utility, but you will never get the quota-calculation improvements without doing the full conversion.  For clarify, this utility is separate from the conversion script. 

Points

The conversion utility in 2.5.x was fully tested for MySQL. Cambridge migrated data using the conversion utility configured for MySQL.  UCT has *not*
Oracle utility should be worked out by midmarch. 
No testing of utility on QA servers?
If any Oracle users are interested moving to 2.5.0 before the changes are committed to 2.5.x, please contact Jim Eng for information about using the conversion utility that will be in post-2.4.

The Jiras related to this, such as

The conversion scripts for content provide SQL to add the new columns needed for binary-entity serialization and the new quota query.
Those are enough to get 2.5 running, but before getting full advantage of the quota query, the conversion utility must be run.
The order for doing this would be:

1) run the conversion script to add the new columns
2) start up sakai 2.5
3) run the conversion utility

When the conversion completes, sakai 2.5 will automatically start using the new code.

We have done a lot of tuning of the SQL in the oracle conversion. Ian said the Oracle conversion was tested on small sample data.  We found severe performance issues when trying to run it against copies of our production database (~6 million records in the three tables). Our Oracle DBA suggested a number of improvements to the SQL used in the conversion. Those improvements are in a branch that has not been merged back to 2.5.x or trunk.

Review of Accessibility bugs.

Mike Elledge, the lead of the accessibility wg, was asked to rate the top 5 accessibility bugs so we can work to get these addressed in the 2.5.x branch (and hopefully a maintenance release).  The top contenders are:  

  • SAK-11679 Accessibility: Inaccessible dialogue box content (Wiki)
  • SAK-11665 Accessibility: "Add" and "Actions" rollovers not recognized as combo boxes (drop down lists) by screen reader (Resources)
  • SAK-11426 Accessibility: Tab Order and Functionality problems (Resources)
  • SAK-2773 Accessibility: Accesskey for worksites lands on "Logout" button (Global)
  • SAK-8233 Accessibility: Retain focus after changing tab location in Preferences > Customize Tabs

We also need to do something about the FCK Editor, either make it accessible or offer TinyMCE as an alternative (SAK-11783 Accessibility: Multiple accessibility problems with FCK editor). That's the biggest accessibility issue we face at present, but it seems like it is out of scope for this. Of course, I would be thrilled to find out that I'm wrong.

Release Status

  • Time line Review - Beta2 tag cut on 9th.  RC1 should be cut and deployed by the time this meeting is held
  • Progress -
    • There are over 70 bug fixes going in from beta to beta2.  We were  down to 47 awaiting verification last week.  This week there are 39 awaiting verification
    • We're seen a lot of progress in the list awaiting verification.
    • % Bugs Verified

    • Date

        • Awaiting Verification

      # Verified

      %

      1/11/2008

      453

      720

      ~61%

      1/30/2008

      405

      773

      ~66%

      1/14/2008

      431

      799

      ~65%

  • Areas to focus on - http://bugs.sakaiproject.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=11510

JSR-170 in 2.5

Summary of rationale for inclusion:   The technical merits of the proposal to merge in JSR-170 into 2.5.x were not a factor in the concerns that were raised.  Much of the discussion rose around violating our current processes (ie breaking code freeze) and the desire that changes to this process should be made in the future.  Given that the there is strong support from the development team, test plans to ensure that adverse effects are not felt, community willingness to assume the risk, community support to exercise the (experimental) code in production, and that this leverages our resources is the best way possible, that the recommendation is that these changes should be merged into 2.5.x after the beta2 tag has been cut. Rest assured, release process refinement will occur.

Testing Plan 

Steve Gitehns put up a to make sure that jackrabbit is really disabled and not doing anything. It will have to be run by someone with read access to the servers file system, logs, and database. The test plan for the JackRabbitService on the Test Plan/Scripts page on the attachments tab:

http://bugs.sakaiproject.org/confluence/display/QA/Test+Conditions+and+Scripts

In addition to compile time unit tests, Steve also wrote a small validation test that can be run against a live server to make sure it really is disabled with our deployment configurations.  There are 3 versions of it:

- A Jython script for Sash using the standard python unittest module.
(Obviously no one can run this until I get off my arse and tag another version of sash).
https://source.sakaiproject.org/contrib/jcr/disabled-jackrabbitservice-tests/JackRabbitServiceTest.py

- A Standard Sakai JWS WebService and Client that can just be dropped in.  At the moment this is probably the only thing that doesn't require installing extra stuff on the QA servers.  This is not a real JUnit check, but just checks the 5 conditions manually and reports with a human readable string.
WS:
https://source.sakaiproject.org/contrib/jcr/disabled-jackrabbitservice-tests/DisabledJackRabbitServiceTest.jws
Client:
https://source.sakaiproject.org/contrib/jcr/disabled-jackrabbitservice-tests/JwsDisabledJackRabbitServiceTestClient.py

- A TestRunner test with a real JUnit test.  (Depends on having the testrunner installed, although you can the test without the GUI, again I need to get off my behind and finish polishing up the half finished GUI for it).
https://source.sakaiproject.org/contrib/jcr/disabled-jackrabbitservice-tests/DisabledJackRabbitServiceTestRunner/

So far we're only testing that JackRabbit is disabled, will be adding some tests to make sure it's enabled and working as we go forward.  (smile)

Testing/Resources Needed

  1. Those  read access to the servers file system, logs, and database to run through manual verification (Megan can do this but would like for this to be done by others. )
  2. Someone to run validation test against live server

UPDATE:  Manual and WS test run @Gtech.

Overview of Time lines & Goals  (Standing item)

Timeline Review
  • Nov 7 tag 2.5.0.012
  • Nov 22 2.5.0.beta cut
  • Nov 26 2.5.0.beta deployed to QA network
  • January 9th 2.5.0.beta2 cut
  • January 10th deployed to QA network
  • Week of Jan 28th - RC1 cut
Goals
  • Elimination of all outstanding Blocker and Critical bugs for 2.5
  • Acceptable Performance testing on mysql and oracle databases for Assignments, Resources, Forums, GB & T&Q. What is acceptable? At this point in time, no degradation from performance experienced in 2.4
  • High degree of verification (85%) of resolved JIRA bugs
  • Confirmed functional testing on all tools.
  • Positive feedback from sites running a tagged version of off branch.

Stats on Issues Reported 

Progression

Q: How do we move from Beta? RC?
A: To make the progression from beta to release candidate, the aim is the resolution of outstanding blocker and critical bugs reported.

Q: Are we going to make the move from Beta to RC?
There are a number of critical issues reported against a 2.5 build we're not likely to get movement on due to resources being unavailable. What do we do with these problems?

A:  Some of them will be resolved in the next release or later in the maintenance branch.  These items should have a target version set and include comments in the rationale as to why they can't be resolved now.

Meeting Notes

Update from Cape Town:
A bit busy because term starts tomorrow. Turned on Search. Most thing resolved, but a few new ones have shown up. Looks like indexes are being lost in the journal. Having started graphing the ratio of bugs report to unique users.

Updates from Testing and Developers:
Georgia Tech: SAK-12691, not sure how the file needs to be imported from the forums. SAK-11963, cannot click on the customize tabs. Cannot probably close since the documentation has been updated, but if there are still problems should file a Jira for it.

John Hall SAK-81128 RSS JavaScript thing. The five feeds seem ok in Firefox, but not in IE. Looking into it.

How to close out a bug?
Once you verify an issue, ideally you say where you tested it at (example, QA-3US, QA-1UK) and what build you did it on (2.5 RC1), but a summary of what how you tested to verify it. Then just close it on the sidebar.

Anthony: Andrew created the test rep yesterday, so I can begin testing the final artifact creation and deployment. The install guide should be ready to go, going to ask some people for comments.

Megan: QA-3 There are some screwy issues on this server. Also, on QA-1 UK, in the assignments seems to be in GB locale translation by default.

Content Tool Translation Update (Jim Eng):
Can make these schema changes by running the script or using auto.ddl. Those schema changes have to be run to run 2.5. These are for performance issues, new binary (instead of xml) serialization, cleanup of object creation and destruction. There were some workarounds in the past for calculating quotas, in this release the new columns fix these performance issues. The new serialization happens on all new items, and when previous changes are touched. But there is also a utility to do the migration, that will go through and touch every row to update them to binary serialization. The quota query isn't useful until this happens. Load testing seems to indicate there aren't problems to run this on the actual production database.
Has not been fully tested at Cape Town yet, partially tested.
Oracle version of queries need some work still. Working on a 2.4.x and post 2.4.x utility, and then will bring the utility forward to 2.5.x after the release. Will be doing testing as we go forward and are working as fast as we can. By the end of next will have a test of our production instance done.

In general, we think the utilities are basically ready, except for the Oracle version.

Q. What to do about the binary version of Sakai Distribution?
A. You can use the option to do it automatically on startup.

In a cluster, you can start up with one of the servers running in this conversion mode.

Q. Is there any existing documentation on this?
A. Not really, this needs some documentation in the release notes, or some where more easily accessible than the buried README file.

Needs to be brought up to the top level.

There is a similar conversion process needed for assignments.

[QA:[ More discussion about the status of the scripts on different databases ]]