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).
