Forum OpenACS Development: More worker bee jobs

There are plenty of worker bee jobs that would really help us get a much better release. Here are a few off the top of my head, feel free to post others that you can think of:

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

Others?

/Lars

<blockquote> Wouldn't it make sense to ask for people interested in
taking over worker bee jobs, along with their preference
what they'd like to contribute to the process?
</blockquote>

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.

/Lars

Ok, here's another thing to test:

- Test that you can delete a package instance with data, in addition to uninstalling the entire package.

Template ad_page_contract error pages.

Well, any error page, really, but these are the worst.

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.

Tom, your "soft delete" thing - aka, leave the acs_object references dangling so we can immediately re-use them later - sounds interesting. In your particular example, I'm not clear on why you couldn't upgrade the table in place. But regardless, maybe "soft delete" is something the data model should eventually explicitly support, to aid in upgrades or whatever.

Is there a process for worker bees to contribute what they do back into the world?

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.

Thanks - I have been here forever and never clicked on the patches/new patches button in bug-tracker. Mea Maxima Culpa!

I'm on it :)

Alfred, thanks for underlining one of the community's greatest failings. This is the most important issue to address once the governance is worked out.

talli

Alfred, permission granted :)