Forum OpenACS Development: More worker bee jobs
- Make sure all packages install and uninstall correctly, also if there's content, permissions on objects, etc. We might not want to tackle uninstall for this release, but on the other hand, it shouldn't be that hard, all it requires is that you continuously run the -create.sql and -drop.sql scripts and are willing to hose your dev server when things break. (Hint: pg_dump). When dropping service contracts, it's probably helpful to take the opportunity to move service contract creation/destruction and implementation registration/unregistration into an APM Tcl callback. See notifications for an example.
- Internationalize packages: Go through all core packages, packages used in .LRN, or packages you care about, and internationalize them. Many packages are already internationalized, but the messages keys are frequently screwy, poorly named, split arbitrarily into separate message keys, etc.
- Write test cases. Pick a Tcl API and decide to exercise it through some test cases that preferably don't assume anything about how the API works internally, so it's good if it exclusively exercises the API. See acs-authentication/tcl/test/ for some examples.
- Go through the bugs and see if they need clarification, and if you can reproduce them on the test servers, and post the result. If you could not reproduce, resolve as "Not reproducable".
Hm. I'm sure there was more, but I can't think of them right now. I'll post when I think of them.
We had a testing team in place for 4.6 if I'm not mistaken. Setting this one up again would help tremendously in the tasks you mention above.
Furthermore, we need to encourage the package maintainers to do some of the tasks mentioned above themselve. E.g. internationalization, writing test cases, and making sure the package at least installs and uninstalls correctly. Honestly, I would kick out any package that does not adhere to that standard for the 5.0 branch.
> taking over worker bee jobs, along with their preference
> what they'd like to contribute to the process?
I thought that's what I just did ... at least I meant to encourage people to come forward either by posting to the thread, private email, or IRC chat, and say "hey, I'd like to contribute ...".
Anyway, I'm not convinced our current package mantainer structure works all that well. In theory, I agree, but if someone who's not a maintainer for a package wants to i18n it, and the so-called package maintainer isn't doing anything, and it gets code-reviewed by an OCT member, be my guest.
Finally, we've never supported uninstall. Forums has never uninstalled, for example. I honestly don't find this a release show-stopper, though I definitely think it's something we should strive to fix. Which is why I put it on the list. But I could easily see there being other more important problems to fix.
- Test that you can delete a package instance with data, in addition to uninstalling the entire package.
Well, any error page, really, but these are the worst.
Your contributions in the matter would be most welcome.
They have never worked if you _ever_ add permissions other than setting the context_id to some value. Also if a package creates groups or anything like that, forget it.
Andrew, I also was surprised. You would think that if you have a group.create, that group.delete would exactly reverse that. But somehow the whole delete thing didn't work out.
Recently I needed a package with data. And I needed to reload it from time to time. I used groups, new relationship types, relational segments. I had to create a whole set of delete functions to loop over stuff not deleted, just to get rid of all the junk.
Of course, not having a delete that works means that testing the package create scripts is hit and miss, something you don't ever want. I think there has been some recent work on fixing this.
I also recently had a need for a 'soft delete'. Imagine your data is stored in the myobject table. I needed to upgrade the datamodel, but I wanted the data. column types were changing, so I couldn't do it in place. So I created myobject_tmp using the new datamodel, and selected the data into this table.
The soft delete dropped the myobject table, but left the data in acs_objects, then I recreate the table and other stuff with the regular, upgraded, create script and reload the data.
I may not have needed to do it, but one attribute was varchar and needed to be text. I also added a few not null attributes. I thought by the time I figured that out, for several tables, I could write the save/restore script. Then a few days later I made more changes and only spent a few minutes on the save/restore.
I think this also points to the fact that developing with real data can make you realize shortcomings pretty quickly.
The current setup allows committers to commit, with no clear place for anyone else to participate.
The three things I see being done in this community:
Branch/rewrite a module and host it on your own site. Might get picked up as part of the core someday (but probably not).
Create a module and post it to file-storage.
Describe in /bug-tracker how you would fix the problem. Wait for a core team member or committer to fix it.
Would it make sense to have a "lamer - we don't trust your code" branch where people could post or use patch-diff and file-storage or something?
How should this be done? I'm willing to help with stuff, but the way things are setup it's always been easy to convince myself that actually getting code to anyone would be too much of a hassle, and therefore not worth doing in the first place.
Just submit a patch to the bugtracker on whatver bug you are working on. We are trying to keep up with the bugs and patches.
The other option is to request CVS commit to a package. Generally after you have submitted a few patches that have been accepted.
I'm on it :)
Here are the instructions for creating patches: http://openacs.org/bugtracker/openacs/patch-submission-instructions.html
which is linked from the New Patch page in bugtracker.