Forum OpenACS Development: Remaining work for 5.0.0 release
- 1 Sev 1 bug must be fixed and 12 Sev 1 bugs must be verified.
- 5 Sev 2 bugs must be fixed, and 8 Sev 2 bugs must be verified.
- 39 Sev 3 bugs could be fixed, and 50 sev 3 bugs could be verified.
- 5 failing autotests need to be fixed. Some of these tests have been checked in in anticipation of upcoming fixes, which is great. Happily, these tests link to the relevant bugs in their descriptions, a practice which we are making standard going forward. When we achieve this, we can release 5.0.0rc1. The criteria for judging and rc release to be Final are a bit skimpy; two were discussed in the last OCT meeting, including an OCT vote of approval (rejected) and requiring that an RC tarball be up for a week without any new Sev 1 bugs found before it is declared Final.
- We have no open or untested critical bugs
- 5 open Sev 2 bugs and 5 resolved Sev 2 bugs remain
- We have 44 open Sev 3 bugs, of which 3 are show-stoppers.
- We need to re-synchronize with the translation server. This has been a risky and time-consuming task in the past; we are working on new code to make it much easier and won't sync until that code is complete.
At the current rate, I expect we will meet our minimal criteria the middle of next week. Note that we will still have perhaps 40 known Sev 3 bugs unfixed. This is acceptable according to our release criteria, but it is certainly not desirable. If you have been waiting for the right time to fix a Sev 3 bug, that time is now.
1231: Notifications fails to install on oracle (found today - I am working on this one now)2-Major
- 1144: users duplicated in cc_users (Lars, Don, Dirk looking at it).
- 1226: .LRN class members can create/edit/delete calendar items (assigned to Dirk)
- 1117: www/admin/permissions-user-add.tcl does not scale (Lars looking at it)
- 857: Logger broken on Oracle (maybe shouldn't be blocking). 3-Normal/Priority-1
- all the core packages have upgrade scripts. I interpret this to mean that any site back to 4.5 can be upgraded to 5.0.0 via the APM. If there is an alternate inpretation, please post it as a TIP. We have not met this criterion; Daveb is currently working on it.
- All Severity 1 and Severity 2 bugs fixed or postponed and Test team verifies no blocking bugs. Blocking bugs are those designated Priority 1. (This is not a good system. We'll fix it after we upgrade 5.0.) We have 4 remaining blocker bugs:
- Translation server data synchronized to branch. Collaboraid has committed code for an improved synchronization process and is testing this code; it still remains to upgrade the translation server so that it has this new code, and then to use it to synchronize the data on the translation server to the branch.
(We did not have a formal vote so that is of course my interpretation, but you can look at the irc log).
Anyway, I second Jeff in saying that the OCT has been in the meetings in favour of a manual upgrade from 4.6.3 to 5.0 to get the release and not treat the non existance of an automatic upgrade as a blocker for release.
Anyone with an existing 4.6.x site who can try an upgrade would be great! We want to test a base 4.6.3 install upgrade to 5.0, but testing with real data would also be helpful.
Also, I don't imagine it's that relavant but I am not aware of any testing on 8.1.6 so maybe that should say "Untested".
#1172 has been bounced back to Peter Marklund for either some explanation or a fix depending on what he wants to do. The code's a bit convoluted, apparently because it is used elsewhere, not just by the add-one-user code, and I figured he could tell me what's going on much more efficiently than I can try to figure out what's going on in that code. The bug's obvious, what's not obvious is how to fix it without breaking other chunks of code that call upon it.
I think Dirk was going to revisit the calendar problem, which he thought was fixed.
Hopefully that's it and once the test servers get rebuilt Lars can confirm it's ok.
- Creating a guest user no longer works.. A fix was committed today; if it is not to the submitter's satisfaction, I suggest we demote the bug to not being an OpenACS blocker (it's a dotlrn bug anyway).
- Translation server. The code to make upgrades easy and safe has been committed. Remaining work is
- an intermittent failure in the automatic tests must be tracked down and fixed
- The translation server has to be updated with the new code and then new translations have to be merged back.
- Upgrades. As far as I know, several people have upgraded successfully; in each case it has taken several days and many manual steps plus some bug fixes. I would say that we have not met our upgrade criterion yet.
A conservative ETA for this work is early January.
As far as upgrading goes ... has anyone tested Oracle or is it just Postgres that people have upgraded?
I'll probably ask that in today's OCT chat :)
- all the core packages have upgrade scripts. I have defined five different levels of strictness for this criterion, and will put this on the table for the next OCT meeting, followed by a vote or TIP.
- All Severity 1 and Severity 2 bugs fixed or postponed and Test team verifies no blocking bugs. Done. (Thanks everybody!)
All core packages have automated tests, not necessarily complete, and pass the tests. The number of failed test cases has been creeping up, and as of today we have 24 failed Oracle test cases and 6 failed PostGreSQL test cases. Due to cascading and related errors, these probably represent 4 and 3 different issues, respectively. I believe that we can punt on all of these:
- One test is for bug 1144, which is punted
- ad_html_to_text_clipped_link fails, but it doesn't seem critical
- acs_templating group_tag fails, but it doesn't seem critical. Bug 428.
- Some of the acs_lang upgrade tests fail on Oracle but not PostGreSQL. Initial inspection suggests that these would require refactoring acs_lang to add a better multi-field primary key to one of the upgrade tables. Failure to fix this shouldn't block release, especially since we've explicitly voted that translation server isn't a blocking issue.
It has been tested by at least one person. It would be good if we could get some more tests, especially on actual sites that have some data in them.
Feedback on the instructions for the procedure would also be helpful.
Help is especially needed for testing Oracle upgrades, though we are not stopping the release if this remains untested.
- the acs-kernel 4.6.5-4.6.6 upgrade script gave 2 errors which seem unimportant:
ERROR: duplicate key violates unique constraint "users_pk" ERROR: relation "admin_rels" already exists
- the acs-kernel upgrade 5d7 to 5d9 script gave me a couple errors because it couldn't drop 2 tables. Moving the 2 'drop table' commands to the end of the file fixed that.
- The first time I tried to login, the login form bombed with the error: "can't read 'defaults': no such variable" inside template::form::create. Restarting the server again mysteriously solved the problem.
- Upgrade failed for static-pages (can't insert duplicate key into apm_package_versions) and acs_messaging (couldn't find a function acs_message__new to drop). I didn't look into fixing the static-pages error, but commenting out the 'drop function' in acs-messaging's upgrade 4.62-4.63 script allowed it to upgrade. Looking further, I think my site was at acs-messaging version 4.6.3 in the DB, but the .info file reported 4.5, thus causing this error.
I also note that I didn't need to load the postgresql.sql file. pg_dump seems to be fixed, at least in 7.4.
1. First we need to fix the broken acs-lang upgrade test case on the Oracle test server. My suspicion is that the cause of the failure is a violation of the lang_messages_audit_pk constraint which is on (package_key, message_key, locale, overwrite_date). I suppose it is the overwrite_date that is identical for two inserts although I would have thought that sysdate would be granular enough for this not to happen. A fix would be to make lang_messages_audit use an integer primary key instead. Making this change should be straightforward and shouldn't be more than 1 work day.
2. Merge the latest message catalog files on the 5.0 branch with the translations on the translation server. This involves importing the 5.0 catalog files to the translation server, resolve any conflicts in the acs-lang admin UI, and then export the result and commit it on the 5.0 branch. After that we should run my catalog consistency check script on the 5.0 branch and see if any keys should be removed or are missing. I think it's best if I do this and I think we're looking at another work day.
[joela@samoyed joela]$ cd /var/tmp [joela@samoyed tmp]$ cvs -d /cvsroot checkout -r oacs-5-0 openacs-4 cvs checkout: in directory openacs-4: cvs [checkout aborted]: *PANIC* administration files missing [joela@samoyed tmp]$
by the web group rather than the cvs group which I fixed).
See if it works now.
I hit this error for dotlrn, so I didn't make dotLRN 2 RC1:
[joela@samoyed dotlrn-packages]$ cvs -d /dotlrn-cvsroot checkout -r dotlrn-2-0 dotlrn-all cvs checkout: Updating bboard-portlet cvs checkout: failed to create lock directory for `/dotlrn-cvsroot/bboard-portlet' (/dotlrn-cvsroot/bboard-portlet/#cvs.lock): Permission denied cvs checkout: failed to obtain dir lock in repository `/dotlrn-cvsroot/bboard-portlet' cvs [checkout aborted]: read lock failed - giving up