I propose to roll back the following recent changes to acs_objects, and postpone to 5.2.
- TIP #43: Adding object_name to acs_objects (https://openacs.org/forums/message-view?message_id=158875)
- TIP #42: Adding package_id to acs_objects (https://openacs.org/forums/message-view?message_id=158870)
- TIP #44: Service Contract to resolve the url from an object_id (https://openacs.org/forums/message-view?message_id=158903)
Also see this thread: https://openacs.org/forums/message-view?message_id=167300
I think the changes implement some very important and desired functionality, but it comes at a great risk to our 5.1 release.
Here's why:
- We need to ship frequently, so people can take advantage of the rapid pace of improvements to our software (software is useless unless you ship it).
- We have decided to cut scope when required to meet release targets, due to our limited resources (can't just throw more bodies at the problem).
- This commit is huge, destabilizing, is 5 days late, it breaks installation, and is likely to introduce many more subtle bugs down the road.
- It's my impression that at the point right before this commit, 5.1/HEAD was fairly stable, and could be tested, stabilized, and released relatively quickly.
- This has to do with the fact that, aside from this particular change, 5.1 was mostly a simple, incremental upgrade, with no radical changes. I would like to keep it that way.
Therefore, I'm suggesting that we roll back this commit, and focus all efforts (hopefully including Timo's) on stabilizing and releasing 5.1 as quickly as absolutely possible.
Ideally, we want all community effort to go into shipping 5.1, rather than fixing and playing with Timo's new changes. So perhaps we could ask Timo to work privately for another week or so, until install, upgrade, test cases, and cursory browsing works again, then commit.
This would also help break our expensive (in time, resources, frustration) habit of committing broken functionality.
And we will have the chance to do the work more thoroughly, including removing duplicated columns between acs_objects and CR, and to go through applications to make sure they use it (which will probably uncover some requirements, we hadn't thought of).
Then this much desired change can go in as soon as we have branched, and Timo and all effort can go towards stabilizing and taking advantage of this change.
I do want to stress that I'm grateful to Timo for doing this important piece of work. I see these changes as critical to OpenACS going forward, and it's great to see the enthusiasm and confidence and ability to getting it done. Thanks, Timo!
/Lars
