Neophytos,

I've added some of the documentation work that will get done for the next release to our new TODO list, so you can see what we'll get done for acs-core-docs (package I and Vinod maintain).

Let us know of other issues that you think could be addressed in the toolkit, and we'll probably add it to the TODO list. Right now it only has things I cold remember off the top of my head (late at night), but I'm sure it'll grow

The list is at http://dev.openacs.org/projects/openacs/developers/todo

Roberto and myself will maintain a todo list much in the same way that it is done at postgresql.org. More about this in an another thread.

Do you think the "20 things to remember.." will be useful to 4.6? If yes I will speed it up a little. Atleast we have 20 things that developers can agree on.

Yes, I think it's useful. Just the other day I was talking to Dave (or was it Roberto, I'm not sure) that we need to enable the general-commnets package so that I could move that document in the new site's developers section and you would be its maintainer there. For 4.6 this is nice to have but not required. If there are no objections, future releases will require it. We need a quick release, now.

I suppose it's obvious by now that Neophytos has kindly offered to take over the mechanics of organizing work on this and the next (I hope) release?

Thanks Neophytos!

The todo list is a good idea.  Sometime it would be nice to integrate Ben's old todo package into 4.x so everyone could have their own personalized TODO portlet on their home page, staring them in the face every day :)

I don't expect core changes for this quick release, I want to start 4.7 planning in parallel with this release effort though.

The big idea here is to get a release out very soon that works with dotLRN PG/Oracle so dotLRN downloaders don't need to grab a cvs snapshot.

However, it's important that we make the development process open and *transparent* to the community.

Oh, it will be. As far as 4.7 goes the only real "planning" has been a conversation Lars and I had over coffee (with a bunch of other OpenACS folks who had come to the Amsterdam social). Lars will have some notes available for public consumption, we've all been consumed by the dotLRN governance and related issues.

Well, I have anyway.

And I want to float some proposals for work on improving the scalability of permissions and some work in the area of the groups datamodel in 4.7.

But before I can float a proposal I need to find the time to do some more research. I have some ideas in my head but need to verify that they are possible to implement - along with upgrade scripts - in reasonable time.

So ... I don't think there's any "hidden" planning going on in practice, just a desire to put together some well thought-out proposals rather than hare-brained schemes.

As far as 4.6 I know that Cathy Sarisky has been working on fixing bugs in the bookmarks package (PG version), she's on IRC all the time so you can ping her on that.

We need to keep this 4.6 list as modest as we can so we can have adequate testing of the toolkit itself, and also adequate testing with dotLRN (which increases our testing burden).

Neophytos - you probably need to ping Simon about testing. He's been silent the last few days (usually means he's busy with clients) and we need to know if OpenMSG can help organize testing again like they did for 4.5.

Neophytos,

Here is a list of packages that I have worked on and plans for 4.6:

• acs-content-repository
  • remove RI workaround triggers (or make them conditional on pg version if we are still supporting pg 7.1)
  • Add xml import/export support of content revisions
  • Test rule dropping for custom content types
  • Add drop column support for custom content types (pg 7.2 feature)
  • Eliminate java code
• acs-kernel
  • cleanup of sql code (naming conventions)
  • Get rid of data-change violation workaround code.
  • Eliminate java code dir
• acs-templating - convert template db api to std api
• acs-workflow (since this has been ported to a newer version, I'm assuming that somebody else is maintaining it)
• Openfts - finish release of 0.33 version for tcl module
• CMS - convert template db api to std api.

Mostly these are cleanup items that I put off after the initial porting effort. In addition, I'm taking advantage of new features now offered in pg 7.2.

# acs-workflow (since this has been ported to a newer version, I'm assuming that somebody else is maintaining it)

Lars and I have talked about workflow, there should be some written stuff available to talk about "real soon now".

Dan, since you're involved with both CR and FTS stuff ... would you have time to investigate fixing some broken datamodel pieces? For instance file storage derives its content revisions from content_item rather than content_revision. This is broken :( I think fixing it would require fixing the interface to the search package as well and upgrade scripts are likely to be messy. But the sooner we fix it, the fewer the number of existing live sites will have to deal with an upgrade.

We've just updated the todo list with the items claimed in this thread thus far. I'm gonna update the project status page next couple of days to give more time to the people who haven't yet posted to do so. Some packages that are obvious are the following but please confirm whether you are maintaining them or not so that we know which packages can be assigned to someone else.

• etp (museatech and/or davb)
• attachments, forums, notifications, acs-mail-lite, user-preference(openforce)
• bugtracker (lars)
• authorize-gateway, payment-gateway, shipping-gateway, payflowpro, sample-gateway, value-based-shipping (furfly and/or bart)
• static-pages (davb)
• cronjob (tom)
• ecommerce (bart)
• spam (til)
• bookmarks (CSari)
If possible specify who's responsible within the company for each package. I'm not sure about some of the items above so please take the time and confirm.

You'll also notice that there are a lot of packages that are not listed here. People have helped port them but may not be interested in maintaining them. Please post for those that you did take responsibility and we'll see what to do with the rest -- we'll probably assign them to area maintainers, e.g. I could maintain the web services area, etc...

BTW I'm hoping 4.6 is the last of the "monolithic tarball" releases, since we'll have new site up soon and will be able to set up nice repositories for packages etc.

We'll probably want to make various monolithic tarballs available (there's been talk elsewhere about various packagings that we might want to do and there needs to be much more talk) but we shouldn't be requiring every package to hit their mark when the core packages do.

The repository approach would allow Lars to finish bugtracker and release it (say) after 4.6 but before 4.7 for instance.

The repository approach would allow Lars to finish bugtracker and release it (say) after 4.6 but before 4.7 for instance.

Of course. All application packages could be released independently but I guess this won't be such a good idea for services.

Lars could even start a .BUGTRACKER consortium if he wanted to :)

One question though is how we should adapt our development model. For example, would Lars submit open items in the todo list? How would one contribute or ask for features to the bugtracker (email Lars or post to the forums if that's our development model)? I suppose what I'm asking is whether .LRN/.XYZ would someday become part of the OpenACS CVS tree but at the same time not subject to the development model of the project.

[I only mention Lars here as an example since you mention him.]

Hi Dan,

I am using content_type__create_type that is where RI Triggers are right?  Deleting the content type and calling it again after your fix should be fine right?

I am also inheriting from content_item.  Since that was the default, I should change that to content_revision.  I thought the code was more updated than that diagram.


DonB,

File-storage fs_root_folders does inherit from cr_revisions.  Which I must do too.

Sorry for being late to the game here.

I'm the owner of bug-tracker, and I will be working on it in the coming weeks, but I'm not sure how the timeframe will match that of the 4.6 release, and as discussed, it shouldn't be a problem.

There's currently a bug-tracker up for bug-tracker at

http://clients.museatech.net/bug-tracker/bugs/

The home page for bug-tracker is one level up from that.

Besides, Collaboraid has a page up with our thoughts about OpenACS development, including workflow and other ideas, we're toying with, here:

http://www.collaboraid.biz/openacs/

/Lars

Ooops, here is the link: http://dev.openacs.org/projects/openacs/proposals/

I am listed above as maintainer for the spam package, which is ok for me but since the plan is to replace it as soon as possible with the new bulk-mail package (which I haven't looked at yet) there won't be any development on it from my side.

As Don mentioned, I'm doing some work on bookmarks.  Peter Marklund has also expressed interest (he did the port), and I hope he's still interested.

I can handle the PostgreSQL side, perhaps with Peter.  Maybe someone else will volunteer for the Oracle side (which may need less work)?

To do for 4.6 (PostgreSQL):

1.  Check out the many problems I've seen with 7.1.3, see if they occur with 7.2 also.

2.  Nuke the show-stopper bugs.  (Crashes, inability to move or delete bookmarks.)

3.  Fix subsite awareness.  To do this may require using the entire tree_sortkey from acs_objects, instead of the truncated version currently in use.  (Which means we'd need an upgrade script.)

4.  Fix the interface so that a user with admin privs doesn't add bookmarks to another user's page quite so easily.

Ben, thank you very much for taking the time to reply -- this thread would have been a *lot* poorer without OpenForce posting about the packages they maintain.

It's a good idea, but it's not mine.  The oracle version, as far as I know (never having tried it), supports import/export of content revision items using xml.  My idea, is to move this out of the db and use ns_xml to provide xml import/export for both oracle and postgresql.

Because of my new job, I haven't been as active as I have in the past. For that reason, I'm also opening up all the packages that I've been working on to others who would be interested in maintaining them. I'm still going to be following OpenACS closely, but I feel guilty being partly in charge of documentation when there are probably so many people in the community that could do it better.

Here's the packages that I've worked on:

• acs-core-docs - plans:
  • those that roberto mentioned above
  • incorporate all the comments that people have made on the pages into the docs. I've done a lot of this, but I'd specifically like help with revamping our AOLServer instructions to take into account Pascal's comments about proper security measures on this page (http://openacs.org/doc/openacs-4/aolserver.html)
  • I added a Makefile inside acs-core-docs/www/xml so the HTML docs, example files and images can be created with 1 command (assuming you have DocBook and xsltproc installed on your system). If you do edit docs, please only edit stuff under the xml directory. *Everything* above that directory (ie. HTML files, config files, images) is generated from substrate below the xml directory.
  • enduser's guide (i know that some are working on this)
  • OpenACS for admin guide. I've converted a prelim outline to WP (http://openacs.org/wp/display/453/. Now it needs content Greg McMullan is helping out here.
  • revamp developer guide (update for OpenACS)
• acs-mail and acs-messaging - as Jon mentioned, these should either be combined or perhaps replaced. I haven't touched these in a while, but i wrote some thoughts about them way back when (http://kurup.com/acs/openacs-mail.html). acs-mail has some very rudimentary pieces in place for incoming mail. It also can send out multipart mail. But it's pretty ugly... in any case, i have no plans to change anything here for 4.6.
• download - No plans for 4.6. This package seems to work OK, although it does the *wrong* thing by inheriting from cr_items and cr_revisions. Down the road, this package could be simplified.
• notes - haven't touched this much since I ported it.
• ticket-tracker - also no changes planned for 4.6. A drawback of this package is that tickets inherit from acs_messages, which as mentioned above, may be on its way out.
• ticket-tracker-lite - Got a UI makeover from Jun for 4.6. Upgrade script provided (added 1 PL/SQL function).

Hi Neophytos and Vinod,

Since Ticket Tracker Lite last few changes was submitted by me to Vinod.  I will be glad to help Vinod on that.  Maybe refine those changes if needed.  Also I think my changes was Postgres only.  I can do the Oracle port if needed.

Peter, it's September 15. Yes we will have a project status page that is why I started this thread in the first place and I'm working on it. It will be posted by the end of the week so that everyone takes the time to post the packages s/he maintains.

Samir: unless you've totally rewritten FAQ, we ported it to PG correctly (see
the dotlrn.openforce.net site running FAQ on PG).

Static-Pages : no changes planned
Clickthrough: no changes planned

Neophytos wrote:

Well, after Lars post, I think we need to address this issue. [Lars, nothing personal]. I have nothing against people or companies maintaining packages outside of OpenACS but I think that saying that QWERTYXYZ is an OpenACS package should come to mean something.

I know at least one company/person who plans to distribute their packages built on top of OpenACS in a separate project and of course it's fine with me, IMHO -- in a way .LRN is doing the same, IMHO, which is also fine. But how does Lars bug-tracker (used as an example here) is different than those packages. How do you differentiate an OpenACS package which is subject to the development processes of the OpenACS project and a package that is in the CVS tree but has its own development processes, probably not subject to the development processes of the OpenACS project.

I think I agree with this, but I want to be sure I understand it. Are you suggesting that there ought to be some process by which some (formal or informal) governing body blesses a package as an OpenACS package, thus preserving the branding of OpenACS? If so, then I agree completely. One approach that some standards bodies take is to create two distinct labels: one for something that the manufacturer claims is compatible with XYZ and the other which the XYZ governing body has officially blessed. So, for example, you could have developers who claim their packages are "dotLRN-compatible" or "OpenACS-compatible" without anybody jumping down their throats, but they'd have to get permission to claim that their package is a "dotLRN package" or an "OpenACS package."

Now, in the case, where you have two or more organizations that are each claiming the ability to "bless" a package, you need means of negotiating between those organizations. Note that the problem is not, strictly speaking, an issue of both organizations potentially blessing the same package. In fact, that would probably be a positive thing, because it allows developers to leverage their work across both the base toolkit and the various vertical apps that may be built on top. No, the problem comes when the two bodies have conflicting code requirements in order to get the package certified.

How serious this conflict in requirements is depends on how central the package is. It probably wouldn't be too terrible, for example, if there needed to be a separate "dotLRN-glossary" distinct from "glossary." OTOH, if dotLRN had conflicting requirements for, say, the content repository, we'd have a pretty serious problem.

So, IMHO, OpenACS needs to work out a policy to sort out this sort of issue with developers of add-on applications, whether those developers are consortia like dotLRN or individual companies like Collaboraid. (And yes, I think this policy needs to come from the OpenACS community rather than dotLRN or someplace else. We need to set up ground rules that encourage people to build on top of OpenACS in a way that is fair to everyone and that discourages forking.)

The easiest place to start is with the core. It seems clear to even a non-techie like me that anything that belongs in the minimal OpenACS distribution should be owned by OpenACS. It may make sense to create a non-profit entity that holds copyright on the OpenACS core. Non-core packages are, I think, a bit fuzzier. We need a process.

Neophytos, is this consistent with your concerns?

(though I'd understand and accept if they want to keep the home page on a musea.net URL just to get a little credit from their investment and gift to the community).

I've been planning to start an entire new thread on this issue once the dust settles on 4.6 planning and dotLRN governance.

How do we give proper credit to companies who give code back?

I don't want to muddle this thread with that issue but we need to talk about it in another thread soon. MIT/OF gave tons back (new-portal, forums, etc), Musea's given code, Furfly the first ecommerce port etc etc.

Please, though, not here ... this should be a separate thread in our general forum.

Neophytos,

Bart is the maintainer for

• authorize-gateway
• shipping-gateway
• value-based-shipping

and furfly is the maintainer for

• payment-gateway
• payflowpro
• sample-gateway

Ben wrote : Samir: unless you've totally rewritten FAQ, we ported it to PG correctly (see the dotlrn.openforce.net site running FAQ on PG).

Ben, as I noted in my earlier post in this thread, Dan Chak has committed code I wrote to OpenACS 4.5 HEAD branch, that is what probably you are referring to. I have not rewritten it after that. AFIK, Robert Locke's version is better at least in that it gets rid of custom privileges, and it is upto him ( I sent him the code) and gatekeeper(s) to merge the two versions.

Don,

As you're aware the testing effort would form part of the release process anyway so I'm partly involved.

I have to be honest and make you aware that at the moment we (OM) are stretched for resources so I don't have a great deal of time spare, but if whoever takes this role over needs any assistance/support I'll try to help out. (we'll still organise the testing of course, although if its going to have value this time we *REALLY* need some committed testers...*Wink Wink, nudge nudge*)


Sorry I can't offer more at the moment.

Simon