(Yes, I realize that I might be bumping the message to the top by posting this)

There are other sites that are also using that instance of PG 7.2 on that machine, IIRC. We'd definitely want to upgrade to a newer version of PG when we upgrade the site.

It'd be really nice if we could have different machines answering for openacs.org. I don't have experience with this, and it would be really nice if those who do (sloan, greenpeace, etc.) could post what they have in their setups so we could learn and apply.

I read an interesting report about livejournal.com and the memcached distributed memory caching daemon they came up with. It'd be applicable for oacs.org if we had more thatn one machine answering for oacs.org on the same network.

-Roberto

1. Run the upgrade.sh script on my computer with a recent oacs-5-1 checkout.
2. Once this is successful, make the site available at http://sussdorff.de:8000
3. Upgrade all other packages and fix / document problems along the way.
4. Once it is successful, post a date for the actual upgrade on openacs.org and let people test the upgraded installation.
5. On the day of the upgrade following things will happen:
   1. Announce on openacs.org that all postings done from now on will not be available on the new site.
   2. Make a dump and copy it over to my machine.
   3. Run the upgrade
   4. Install PG 7.4.5 on samoyed.openacs.org
   5. Copy the dump from the successful upgrade on my machine to samoyed.openacs.org and install in PG 7.4.5
   6. Copy sourcecode from successful upgrade to samoyed.openacs.org
   7. Move /web/openacs.org to /web/openacs.org-4.2
   8. Change runfile to run /web/openacs.org-4.2 on port 8005
   9. Move successful upgrade sourcecode to /web/openacs.org
   10. Change runfile to run /web/openacs.org on http://openacs.org
6. Go on vacation

jcdldn: +viewcvs has no datamodel and irc-logger is in contrib

I guess we are set then :)

Do not run:

notifications/upgrade-4.6.1-4.6.2

acs-content-repository/upgrade-4.6.1-4.6.2

etp/upgrade-1.1d-1.2

bug-tracker/(all upgrade.sql). Run them manually after the upgrade. Make sure to use the same user that is the owner of the site.

file-storage/upgrade-4.6.1-4.6.2

It seems that the site is already running on 4.6.2 though noone told the packages this :).

Furthermore, it is wise to run all SQL scripts for forums starting with the second and doing the first one last. I actually added the other upgrade scripts manually to the first one, so it (hopefully) speeds up a little bit.

Run the upgrade.sh.

Copy zzz-upgrade.tcl to /tcl

Start the server.

Remove zzz-upgrade.tcl

Restart the server.

got to /acs-admin/apm/packages/install.

Select *all* upgrades and workflow. *SKIP* bug-tracker.

When you come to select the SQL files, skip the following:

notifications 4.6.1-4.6.2
content-repository 4.6.1-4.6.2
subsite 4.5-xxx
etp 1.1d-1.2
fs everything <4.6.2
forums *all*

install (should run smoothly)
restart the server
install the bug-tracker upgrade
unselect all data-model scripts and upgrade.
run bug-tracker.sql (special file)
restart the server
realize bug-tracker does not work .

You can check it out at http://sussdorff.dyndns.org:8000

As for bug-tracker the problem is that the 0.9-1.2 upgrade script does not work. Which results in the bugs not being imported though everything else. Currently I'm too lazy for debugging this.

Last but not least I won't have time to work on this til middle of November, which sucks, but there is not much I can do to help it.

Suggestions: If someone wants to work on it I can give access on my computer. Just send me a mail.

What needs to be done is ETP (get everything in place, so the pages display something that resembles openacs.org). And to make the upgrade work for bug-tracker. Apparently the way described above had some problem, which is why it failed.

Maybe the notifications could be optimized by allowing users to subscribe to all bugs, or all bugs related to specific packages, in the same manner as forums allows one to subscribe to all threads in a forum?

My thought is that those most active with submitting bugs probably have a large number of notifications that could essentially be triggered on the package level instead.

hmm.. actually I think this is how it works in openacs5.x.  Looks like the answer is (again) to complete the openacs.org upgrade.

As I understand it, current upgrade problems are related to bugtracker. Maybe the task can be made easier by flushing/filtering the notifications related to bugtracker for the upgrade.

upgrade-oo-5=> explain analyze select q.*,
upgrade-oo-5->        km.keyword_id,
upgrade-oo-5->        assign_info.*
upgrade-oo-5-> from (
upgrade-oo-5(>  select b.bug_id,
upgrade-oo-5(>          b.bug_number,
upgrade-oo-5(>          b.summary,
upgrade-oo-5(>          lower(b.summary) as lower_summary,
upgrade-oo-5(>          b.comment_content,
upgrade-oo-5(>          b.comment_format,
upgrade-oo-5(>          b.component_id,
upgrade-oo-5(>          b.creation_date,
upgrade-oo-5(>          to_char(b.creation_date, 'fmMM/DDfm/YYYY') as creation_date_pretty,
upgrade-oo-5(>          b.creation_user as submitter_user_id,
upgrade-oo-5(>          submitter.first_names as submitter_first_names,
upgrade-oo-5(>          submitter.last_name as submitter_last_name,
upgrade-oo-5(>          submitter.email as submitter_email,
upgrade-oo-5(>          lower(submitter.first_names) as lower_submitter_first_names,
upgrade-oo-5(>          lower(submitter.last_name) as lower_submitter_last_name,
upgrade-oo-5(>          lower(submitter.email) as lower_submitter_email,
upgrade-oo-5(>          st.pretty_name as pretty_state,
upgrade-oo-5(>          st.short_name as state_short_name,
upgrade-oo-5(>          st.state_id,
upgrade-oo-5(>          st.hide_fields,
upgrade-oo-5(>          b.resolution,
upgrade-oo-5(>          b.found_in_version,
upgrade-oo-5(>          b.fix_for_version,
upgrade-oo-5(>          b.fixed_in_version,
upgrade-oo-5(>          cas.case_id
upgrade-oo-5(>
upgrade-oo-5(>    from bt_bugs b,
upgrade-oo-5(>          acs_users_all submitter,
upgrade-oo-5(>          acs_users_all assignee,
upgrade-oo-5(>          workflow_cases cas,
upgrade-oo-5(>          workflow_case_fsm cfsm,
upgrade-oo-5(>          workflow_fsm_states st
upgrade-oo-5(>    where submitter.user_id = b.creation_user
upgrade-oo-5(>      and cas.workflow_id = '206311'
upgrade-oo-5(>      and cas.object_id = b.bug_id
upgrade-oo-5(>      and cfsm.case_id = cas.case_id
upgrade-oo-5(>      and cfsm.parent_enabled_action_id is null
upgrade-oo-5(>      and st.state_id = cfsm.current_state
upgrade-oo-5(>
upgrade-oo-5(>    and cfsm.current_state = '10'
upgrade-oo-5(> ) q
upgrade-oo-5-> left outer join
upgrade-oo-5->  cr_item_keyword_map km
upgrade-oo-5-> on (bug_id = km.item_id)
upgrade-oo-5-> left outer join
upgrade-oo-5->  (select cru.user_id as assigned_user_id,
upgrade-oo-5(>          aa.action_id,
upgrade-oo-5(>          aa.case_id,
upgrade-oo-5(>          wa.pretty_name as action_pretty_name,
upgrade-oo-5(>          assignee.first_names as assignee_first_names,
upgrade-oo-5(>          assignee.last_name as assignee_last_name
upgrade-oo-5(>      from workflow_case_assigned_actions aa,
upgrade-oo-5(>          workflow_case_role_user_map cru,
upgrade-oo-5(>          workflow_actions wa,
upgrade-oo-5(>          acs_users_all assignee
upgrade-oo-5(>    where aa.case_id = cru.case_id
upgrade-oo-5(>      and aa.role_id = cru.role_id
upgrade-oo-5(>      and cru.user_id = assignee.user_id
upgrade-oo-5(>      and wa.action_id = aa.action_id
upgrade-oo-5(>  ) assign_info
upgrade-oo-5-> on (q.case_id = assign_info.case_id)
upgrade-oo-5->    order by bug_number desc;
                                                                                                  QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sort  (cost=61090.28..61211.08 rows=48319 width=932) (actual time=13986.656..15343.380 rows=288864 loops=1)
  Sort Key: b.bug_number
  ->  Hash Left Join  (cost=2789.18..4940.99 rows=48319 width=932) (actual time=639.752..11525.309 rows=288864 loops=1)
        Hash Cond: ("outer".case_id = "inner".case_id)
        ->  Hash Left Join  (cost=1135.64..2441.64 rows=48319 width=666) (actual time=172.199..5360.479 rows=288864 loops=1)
              Hash Cond: ("outer".bug_id = "inner".item_id)
              ->  Nested Loop  (cost=1020.33..1400.22 rows=16106 width=662) (actual time=121.938..1925.355 rows=96288 loops=1)
                    ->  Nested Loop  (cost=0.00..57.77 rows=2 width=662) (actual time=0.262..3.768 rows=12 loops=1)
                          ->  Nested Loop  (cost=0.00..53.37 rows=1 width=670) (actual time=0.223..3.129 rows=12 loops=1)
                                ->  Nested Loop  (cost=0.00..52.21 rows=1 width=619) (actual time=0.178..2.463 rows=12 loops=1)
                                      ->  Nested Loop  (cost=0.00..48.57 rows=1 width=596) (actual time=0.141..1.896 rows=12 loops=1)
                                            ->  Nested Loop  (cost=0.00..41.49 rows=2 width=569) (actual time=0.106..1.341 rows=12 loops=1)
                                                  ->  Nested Loop  (cost=0.00..35.61 rows=1 width=12) (actual time=0.070..0.777 rows=12 loops=1)
                                                        ->  Index Scan using wf_case_fsm_state_idx on workflow_case_fsm cfsm  (cost=0.00..32.58 rows=1 width=8) (actual time=0.026..0.191 rows=12 loops=1)
                                                              Index Cond: (current_state = 10)
                                                              Filter: (parent_enabled_action_id IS NULL)
                                                        ->  Index Scan using workflow_cases_pk on workflow_cases cas  (cost=0.00..3.02 rows=1 width=8) (actual time=0.021..0.027 rows=1 loops=12)
                                                              Index Cond: ("outer".case_id = cas.case_id)
                                                              Filter: (workflow_id = 206311)
                                                  ->  Index Scan using bt_bug_pk on bt_bugs b  (cost=0.00..5.86 rows=1 width=561) (actual time=0.013..0.020 rows=1 loops=12)
                                                        Index Cond: ("outer".object_id = b.bug_id)
                                            ->  Index Scan using parties_pk on parties pa  (cost=0.00..3.53 rows=1 width=27) (actual time=0.014..0.020 rows=1 loops=12)
                                                  Index Cond: ("outer".creation_user = pa.party_id)
                                      ->  Index Scan using persons_pk on persons pe  (cost=0.00..3.63 rows=1 width=23) (actual time=0.013..0.019 rows=1 loops=12)
                                            Index Cond: ("outer".creation_user = pe.person_id)
                                ->  Seq Scan on workflow_fsm_states st  (cost=0.00..1.15 rows=1 width=55) (actual time=0.011..0.021 rows=1 loops=12)
                                      Filter: (10 = state_id)
                          ->  Index Scan using users_pk on users u  (cost=0.00..4.39 rows=1 width=4) (actual time=0.013..0.024 rows=1 loops=12)
                                Index Cond: (u.user_id = "outer".party_id)
                    ->  Materialize  (cost=1020.33..1100.86 rows=8053 width=0) (actual time=10.141..58.123 rows=8024 loops=12)
                          ->  Hash Join  (cost=329.57..1020.33 rows=8053 width=0) (actual time=121.638..322.682 rows=8024 loops=1)
                                Hash Cond: ("outer".person_id = "inner".party_id)
                                ->  Hash Join  (cost=158.64..648.08 rows=8052 width=8) (actual time=60.693..180.701 rows=8024 loops=1)
                                      Hash Cond: ("outer".user_id = "inner".person_id)
                                      ->  Seq Scan on users u  (cost=0.00..280.57 rows=8557 width=4) (actual time=0.006..34.454 rows=8024 loops=1)
                                      ->  Hash  (cost=138.51..138.51 rows=8051 width=4) (actual time=60.636..60.636 rows=0 loops=1)
                                            ->  Seq Scan on persons pe  (cost=0.00..138.51 rows=8051 width=4) (actual time=0.007..31.320 rows=8024 loops=1)
                                ->  Hash  (cost=150.75..150.75 rows=8075 width=4) (actual time=60.900..60.900 rows=0 loops=1)
                                      ->  Seq Scan on parties pa  (cost=0.00..150.75 rows=8075 width=4) (actual time=0.007..31.528 rows=8045 loops=1)
              ->  Hash  (cost=98.85..98.85 rows=6585 width=8) (actual time=50.218..50.218 rows=0 loops=1)
                    ->  Seq Scan on cr_item_keyword_map km  (cost=0.00..98.85 rows=6585 width=8) (actual time=0.013..26.073 rows=6585 loops=1)
        ->  Hash  (cost=1653.53..1653.53 rows=1 width=266) (actual time=467.482..467.482 rows=0 loops=1)
              ->  Subquery Scan assign_info  (cost=946.14..1653.53 rows=1 width=266) (actual time=467.474..467.474 rows=0 loops=1)
                    ->  Hash Join  (cost=946.14..1653.52 rows=1 width=44) (actual time=467.466..467.466 rows=0 loops=1)
                          Hash Cond: ("outer".user_id = COALESCE("inner".deputy_user_id, "inner".user_id))
                          ->  Hash Join  (cost=502.90..1170.00 rows=8053 width=31) (actual time=122.691..321.421 rows=8024 loops=1)
                                Hash Cond: ("outer".person_id = "inner".party_id)
                                ->  Hash Join  (cost=331.96..797.76 rows=8052 width=27) (actual time=61.971..172.555 rows=8024 loops=1)
                                      Hash Cond: ("outer".person_id = "inner".user_id)
                                      ->  Seq Scan on persons pe  (cost=0.00..138.51 rows=8051 width=23) (actual time=0.007..29.966 rows=8024 loops=1)
                                      ->  Hash  (cost=280.57..280.57 rows=8557 width=4) (actual time=61.847..61.847 rows=0 loops=1)
                                            ->  Seq Scan on users u  (cost=0.00..280.57 rows=8557 width=4) (actual time=0.010..32.245 rows=8024 loops=1)
                                ->  Hash  (cost=150.75..150.75 rows=8075 width=4) (actual time=60.683..60.683 rows=0 loops=1)
                                      ->  Seq Scan on parties pa  (cost=0.00..150.75 rows=8075 width=4) (actual time=0.007..31.467 rows=8045 loops=1)
                          ->  Hash  (cost=443.24..443.24 rows=1 width=25) (actual time=117.214..117.214 rows=0 loops=1)
                                ->  Hash Join  (cost=441.81..443.24 rows=1 width=25) (actual time=117.208..117.208 rows=0 loops=1)
                                      Hash Cond: ("outer".action_id = "inner".action_id)
                                      ->  Seq Scan on workflow_actions wa  (cost=0.00..1.28 rows=28 width=13) (actual time=0.006..0.126 rows=28 loops=1)
                                      ->  Hash  (cost=441.81..441.81 rows=2 width=20) (actual time=116.975..116.975 rows=0 loops=1)
                                            ->  Hash Join  (cost=75.63..441.81 rows=2 width=20) (actual time=116.968..116.968 rows=0 loops=1)
                                                  Hash Cond: ("outer".user_id = "inner".member_id)
                                                  ->  Hash Left Join  (cost=0.00..323.38 rows=8557 width=8) (actual time=0.036..88.308 rows=8024 loops=1)
                                                        Hash Cond: ("outer".user_id = "inner".user_id)
                                                        ->  Seq Scan on users u  (cost=0.00..280.57 rows=8557 width=4) (actual time=0.006..30.137 rows=8024 loops=1)
                                                        ->  Hash  (cost=0.00..0.00 rows=1 width=8) (actual time=0.010..0.010 rows=0 loops=1)
                                                              ->  Seq Scan on workflow_deputies dep  (cost=0.00..0.00 rows=1 width=8) (actual time=0.004..0.004 rows=0 loops=1)
                                                                    Filter: ((('now'::text)::timestamp(6) with time zone >= start_date) AND (('now'::text)::timestamp(6) with time zone <= end_date))
                                                  ->  Hash  (cost=75.62..75.62 rows=1 width=16) (actual time=0.301..0.301 rows=0 loops=1)
                                                        ->  Nested Loop  (cost=1.35..75.62 rows=1 width=16) (actual time=0.294..0.294 rows=0 loops=1)
                                                              ->  Nested Loop  (cost=1.35..10.07 rows=1 width=16) (actual time=0.288..0.288 rows=0 loops=1)
                                                                    ->  Nested Loop  (cost=1.35..4.46 rows=1 width=20) (actual time=0.280..0.280 rows=0 loops=1)
                                                                          ->  Hash Join  (cost=1.35..1.43 rows=1 width=16) (actual time=0.274..0.274 rows=0 loops=1)
                                                                                Hash Cond: ("outer".action_id = "inner".action_id)
                                                                                ->  Seq Scan on workflow_case_enabled_actions wcea  (cost=0.00..0.00 rows=1 width=8) (actual time=0.003..0.003 rows=0 loops=1)
                                                                                      Filter: ((completed_p = false) AND (assigned_p = true))
                                                                                ->  Hash  (cost=1.28..1.28 rows=28 width=8) (actual time=0.252..0.252 rows=0 loops=1)
                                                                                      ->  Seq Scan on workflow_actions wa  (cost=0.00..1.28 rows=28 width=8) (actual time=0.013..0.130 rows=28 loops=1)
                                                                          ->  Index Scan using workflow_cases_pk on workflow_cases c  (cost=0.00..3.01 rows=1 width=4) (never executed)
                                                                                Index Cond: (c.case_id = "outer".case_id)
                                                                    ->  Index Scan using wf_case_role_pty_map_pk on workflow_case_role_party_map wcrpm  (cost=0.00..5.60 rows=1 width=12) (never executed)
                                                                          Index Cond: ((wcrpm.case_id = "outer".case_id) AND ("outer".assigned_role = wcrpm.role_id))
                                                              ->  Index Scan using party_approved_member_map_pk on party_approved_member_map pamm  (cost=0.00..65.34 rows=17 width=8) (never executed)
                                                                    Index Cond: (pamm.party_id = "outer".party_id)
Total runtime: 16444.930 ms
(84 rows)

As I'm not able to tune bug-tracker, we have a couple of options:

a) Delay the upgrade til someone tuned bug-tracker
b) Upgrade but leave bugtracker on the old openacs.org

Last but not least, a maybe heretic question: How about tanking bug-tracker altogether for openacs.org and make use of sourceforge (for the bug-tracking)?

Though the last approach would mean we are not eating our own s*** anymore, it has a couple of advantages:

1) We could finally upgrade openacs.org
2) OpenACS would get great exposure on sourceforge

I think tuning the queries and figuring out how to fix bugtracker is worth the effort. I don't think a rewrite to use a different category system will make it any faster, just different.

Bug tracker contains a lot of code to handle categories in a hierarchical manner, if we'd use category system, we could just reuse the functions written therein. Furthermore, it would be a good reason to integrate categories with listbuilder (unless it is already done), meaning, you can map multiple category trees to a package and the listbuilder would display them automatically like the bug-tracker currently does manually.

Last but not least, it would allow us to use multiple categories within one tree, something that would break the current bug-tracker. Useful if a bug e.g. belongs to more than one package.

I also thought of using a combination of categories, AMS and notification to customize a new bug-tracker system. The question is how to incorporate roles.

The question is how to define such a package. Since most of the stuff is customization? Some kind of installer script is required to implement that.

Greetings,
Nima

2. What Jade said, especially the second subquery where only first/last names is needed.  Break the view abstraction and join against persons on person_id.

After verifying that the new query returns the right results, post the new times and plan and we'll work from there ...

In a first step I commented out #oacs_set_login_vars in /www/templates/general-master so you can check out the master template as it is supposed to be at samoyed.

When a SELECT like the notifications query posted by Jeff above does a sequential scan on the objects table when joining on its primary key object_id...

Try the ANALYZE command.

Sometimes you get plans like this after you do:

 Sort  (cost=47.76..47.77 rows=3 width=794)
   Sort Key: notification_requests.user_id, notifications.type_id, notifications.notif_date
   ->  Hash Join  (cost=6.01..47.74 rows=3 width=794)
         Hash Cond: ("outer".user_id = "inner".user_id)
         Join Filter: ("outer".notification_id = "inner".notification_id)
         Filter: ("inner".sent_date IS NULL)
         ->  Nested Loop  (cost=0.00..41.72 rows=3 width=778)
               Join Filter: ("inner".creation_date <= "outer".notif_date)
               ->  Nested Loop  (cost=0.00..13.63 rows=8 width=766)
                     ->  Index Scan using notifications_object_id_idx on notifications  (cost=0.00..7.76 rows=1 width=746)
                     ->  Index Scan using notification_requests_t_o_idx on notification_requests  (cost=0.00..5.85 rows=1 width=20)
                           Index Cond: (("outer".type_id = notification_requests.type_id) AND ("outer".object_id = notification_requests.object_id))
                           Filter: (interval_id = 2889)
               ->  Index Scan using acs_objects_pk on acs_objects  (cost=0.00..3.39 rows=1 width=12)
                     Index Cond: ("outer".request_id = acs_objects.object_id)
         ->  Hash  (cost=6.01..6.01 rows=1 width=16)
               ->  Index Scan using notification_user_map_user_idx on notification_user_map  (cost=0.00..6.01 rows=1 width=16)
(17 rows)

Compare that with the plan posted by Jeff above.

Much nicer ... we'll see if the notification associate with THIS post goes a bit faster!

So the next step is to figure out why this is so.

The upgrade will take 7am GMT, this Saturday. During this time, the site will redirect to a page that warns you the site is being upgraded.

Plan for the upgrade:

Don:

1. Don will work on adding pagination to forums before Saturday, and let everyone know if he doesn't have the time to finish.

Joel:

1. Write up document on how to switch over to cvs.openacs.org in existing CVS checkouts.

Andrew:

1. Make anonymous pserver work for cvs.openacs.org

Malte:

1. Run the upgrade.sh script on his computer with a recent oacs-5-1 checkout (oacs-5-1-compat checkout, right?).
2. Once this is successful, make the site available at http://samoyed.furfly.net
3. Upgrade all other packages and fix / document problems along the way.
4. On the day of the upgrade following things will happen:
   1. Announce on openacs.org that all postings done from now on will not be available on the new site.
   2. Set up an index.vuh file which redirects the old site to a page that lets everyone know that openacs.org is being upgraded.
   3. Make a dump and copy it over to my machine.
   4. Run the upgrade
   5. Install PG 7.4.5 on samoyed.openacs.org
   6. Copy the dump from the successful upgrade on my machine to samoyed.openacs.org and install in PG 7.4.5
   7. Copy sourcecode from successful upgrade to samoyed.openacs.org
   8. Move /web/openacs.org to /web/openacs.org-4.2
   9. Change runfile to run /web/openacs.org-4.2 on port 8005
   10. Move successful upgrade sourcecode to /web/openacs.org
   11. Change runfile to run /web/openacs.org on http://openacs.org

Filtering on the Bug Tracker is largely unusable - the filtering seems to be doing the job, but the page gives you basically no idea whatsoever just what it is you've filtered to.

Formatting of Bug Tracker submissions is hosed, it pops up some weird in-line HTML editor that looks like Microsoft Word, with NO OPTION to switch to the standard OpenACS submission types. AFAICT it is impossible to post HTML to Bug Tracker.

It is rather embarassing to see OpenACS perpetuate this particular bug over and over again. The page of links to the user's contributed content is perhaps the single simplest yet very valuable feature that ACS and OpenACS have always gotten right. (While every single other bulletin board or mailing list archive I've ever seen has always gotten wrong, by either never bothering to think about it at all, or by never having a central user data model to tie it to.)

Heck, Philip G. (and probably others as well) have written about the value of this one simple feature, both extolling its own usefullnes and using it to illuminate the benefits and community centric design of OpenACS as a whole - and yet openacs.org has broken it repeatedly, and now some of its own maintainers apparently don't understand its value! Not good.

• I tried to post my last post (plain text) and this post (HTML) after a "preview" and got this strange bug:

  "The attribute 'value' is not allowed for option tags".

• If I "preview" the current post as "preformatted text" I will notice that I made a mistake (because it contains HTML tags). However if I hit "edit again" to correct my mistake and post as HTML it turns out that all < have been replace by "& lt ;" and I should use the user unfriendly back button in the browser.
• I like the white background. The blue banding is harder to read, IMO
• Please put the "Posted by" line on top of the post. I always find myself scanning for who did the posting before reading the post itself
• We have an "In response to" now. Therefor the repetitive title is annoying and unneccary. Could we make Subject optional in replies (or make "space" the standard title).
• Date should definitely be in there. Anything is better than nothing. Can we use abbreviated month names?
• The login cookie expires while writing this post. That sure is annoying. Is this to enhance accuracy of the members online feature?
• If it is unclear what members online means, we'ld better leave it out. Are we counting guests? At least the people that made themselves "invisible", should be counted, IMO.

Running openacs.org off the stock toolkit is indeed attractive for various reasons, so I recommend simply adding the feature back, but with a setting to turn it on/off. Turn the feature on for openacs.org, leave it defaulted to off in the stock toolkit. Then at your leisure, write a TIP to change the default setting from off to on.

Mainly its cleanup of the code that is long overdue.

I am also looking into enabling the dynamic threaded forums user interface that was included in the Concord Consortium demonstration web site originally developed by Jeff Davis. This is a little tricky, since it was designed to work on OpenACS 5.2(HEAD).

Since it still supports flat forums, but greatly improved the threaded user interface, I think it is the best starting place for a user interface disucssion.