Forum OpenACS Development: Project Manager status?

Collapse
Posted by Michael Steigman on
I've been using v3.0.1d and recently tried to upgrade to the latest tagged version on 5.2 but ran into some major problems. In upgrade-3.1d11-3.1d12.sql, pm_task_logger_proj_map is dropped from the data model in favor of acs_relations but several templates still reference this table. I checked out PM from head and the same problem exists there. It appears there was an incomplete or botched checkin.

Can someone who has worked on the package please address this?

Collapse
Posted by Malte Sussdorff on
This is strange. I upgraded three sites and never ran into this problem.Furthermore, the latest checkout from HEAD does not show this table being referenced anymore. Maybe you forgot to upgrade logger to HEAD as well ? To be on the save side I updated the version number for PM and made the requirements clear on the latest logger.
Collapse
Posted by Michael Steigman on
Ah, so that's a portlet from logger? I'm running logger 1.3 currently. Hmmm... now I have an interesting dilemma - I have a lot of people using my logger instances for time reporting and its function is fairly critical. Is logger on HEAD stable? Is the UI different? I need to be sure that update won't hose the group using logger, which is a lot larger than the group using PM.

Also, on the subject of PM depencies, I was chatting with Dave B the other day and he was surprised to learn that there was a version of dynamic types that had been released. From what I can gather, this was done without anyone's knowledge and now there's a bit of an issue as we have a mainstream app that's dependent on this old version and Lee (package author) has re-written the API. The code is not in CVS yet. They can check in the latest version on HEAD and leave the openacs-5-2-compat tag where it is but that would mean that anyone who would like to work with the latest version of dynamic types AND run PM would be in a pickle. Is it possible for us to all work together and get the new dtypes into CVS and update PM to use the new API?

Collapse
Posted by Malte Sussdorff on
Logger had a lot of dependencies with Project Manager which have been taken out, though you might want to test this first (we never used logger without PM). No UI changes have been made by us, though I am not sure how the old logger looked like.

Dynamic Types has been in CVS for ages now. If there exist other versions which have not been put back into CVS, this is a bad situation, especially if they change the API as one cannot assume that nobody is going to use code committed in a stable branch. Furthermore can't the old API coexist to guarantee backwards compatability ?

Last but not least, there were a couple of bugs in DT which we fixed. If Lee is using his own version,will this include our fixes and UI changes?

Collapse
Posted by Dave Bauer on
Malte,

The issue is that dynamic types was tagged as released when the version was still a development version number.

Maybe it was tagged when the whole tree was tagged openacs-5-2-compat. I am not sure if that is a good idea, because it does not reveal the true status of the code.

So mainly this is a result of massive miscommunication, serveral people working on the same package without talking to each other.

I'll work on commiting the latest dynamic types code, and then we can work together on a solution. I think it makes sense to try to get PM to use the newest apis. I think Vinod also worked on porting your UI elements to the latest dynamic types.

Collapse
Posted by Malte Sussdorff on
If many people have been working on dynamic types package (at the moment I count 5: Vinod, Lee, you, Timo, myself), which was in openacs CVS, why are Timo and myself the only ones comitting changes back in a timely fashion?

How should communication happen if you work on a package? I thought that stating "we are using dynmic types", "we integrated DT with PM" would be sufficient posting in the forums that at least we were working on it and are using it. Not to mention, that I assume people are reading CVS commits of packages they are interested in (and especially the ones they work on).

What are the steps to prevent these things from happening in the future? Here are some of my ideas:

a) If you work on a package, work on it out of HEAD and commit to HEAD. If you fork from the version that is in OpenACS, it will be your responsibility to merge your changes back to the offical tree and make sure, that if you change the API, that all packages in CVS using your API are changed to reflect this (if the old API does not work anymore). At least this is what we did, what was suspected from us and what I would expect from anyone else.

b) Once we can have RSS feeds or notifications for single xowiki pages, post your planned changes to the package page within xowiki.

c) Read the CVS commits, if something changes you don't like, ask the author of the commit for collaboration (so both versions work)

d) If you release a package (version) that relies on a non released package, release the yet unreleased package, make a note on the package page and probably a posting in OpenACS Forums so it does not come as a surprise.

On a related note, has anyone working on dynamic types bothered to look closer at AMS lists concept and DynFields? My guess is that we have a couple of packages basicly doing exactly the same, albeit in different ways, and if we could couple the attribute extension (which stores the attributes either in meta tables like AMS or in the object_type table like DynamicTypes) with the lists concept of AMS (allowing you to have multiple different views on the attributes of an object, depending on context), we would probably end up with something like Dynfields, although with a different UI and different ways to store attributes.

I would propose we sit down together at one time and come up with a common solution which we can put into OpenACS core and gradually change all our applications to use this core package for extending and creating object types. Especially if you suggest we change the project manager to the new dynamic types API, I would prefer to change it to something that supports lists instead in the future (so I could have project attribute forms depending on the type of project, without the need to create a new project object_type for each of the types of project or the need to enter all the data again if I change the type of the project).

Collapse
Posted by Dave Bauer on
Malte said:

On a related note, has anyone working on dynamic types bothered to look closer at AMS lists concept and DynFields? My guess is that we have a couple of packages basicly doing exactly the same, albeit in different ways, and if we could couple the attribute extension (which stores the attributes either in meta tables like AMS or in the object_type table like DynamicTypes) with the lists concept of AMS (allowing you to have multiple different views on the attributes of an object, depending on context), we would probably end up with something like Dynfields, although with a different UI and different ways to store attributes.

I would propose we sit down together at one time and come up with a common solution which we can put into OpenACS core and gradually change all our applications to use this core package for extending and creating object types. Especially if you suggest we change the project manager to the new dynamic types API, I would prefer to change it to something that supports lists instead in the future (so I could have project attribute forms depending on the type of project, without the need to create a new project object_type for each of the types of project or the need to enter all the data again if I change the type of the project).

That's the plan Malte, great ideas. I think all your requests are something everyone will want.

Collapse
Posted by Malte Sussdorff on
Okay, I wrote up an initial document stating some of the aims, so we could collaborate from there on:

https://openacs.org/xowiki/dyntypefields

My goal for the first stage is that we get all the ideas that exist in our heads into this document. Once this is done, we can start branching off by actually defining the API and the needed changes to template::list and ad_form, along with an upgrade path from AMS and dynamic types (and, if Frank agrees to reuse it in project/open, maybe even dynfields).

Collapse
7: How to get dynfields (response to 5)
Posted by Malte Sussdorff on
Frank might correct me, but I used this to find the dynfields package and download it to my harddisk:

cvs -z3 -d:pserver:mailto:anonymous@berlin.dnsalias.com:/home/cvsroot checkout intranet-dynfield