Forum OpenACS Development: Re: OACS 6 and beyond

Collapse
56: Re: OACS 6 and beyond (response to 1)
Posted by Malte Sussdorff on 07/30/06 12:29 PM
"Malte made a more-or-less unilateral decision to stop doing so. How do we stop him from doing so? How do you force him to support Oracle FOR FREE?"

Force wont be helpful at all, probably even counter productive (take into account that at the moment we write -oracle.xql files and /oracle/upgrade/whatever.sql if we are aware that the code we change wont work on Oracle. Its not that we lost our AD training in Oracle altogether). But we are not testing it anymore as we do not need Oracle for the customers we are serving.

What would be helpful though is a server with an Oracle installation of OpenACS, where we could get ssh access to and test the upgrade scripts and other oracle.xql scripts. Let alone run automated test cases. It should be easy (read: "sh reinstall-db.sh") to reinstall the database in case my upgrade script does not work. And as Simon was willing to contribute a server to the split Oracle project "I can volunteer to provide a server and responsibility for maintaining a new community around the oracle version.", maybe he would also volunteer for the provision of such a testing server.

The goal should be to make it as easy as possible for contributors to submit and share their code. And if you ask for the core to remain with Oracle, but are not willing to port things yourself and say that it is in the responsibility of the contributor to commit for Oracle as well, make it as pleasant for him to do so.

Don, please correct me if I am utterly mistaken, but I think the number of database specific commits on core has decreased considerably with the extension of our API. Furthermore, with Neophytos database abstraction layer, the whole point might become mute (just as an example: when writing the invoice package we only had to 7 out of 39 .xql files postgresql specific.)

When I said we are going to drop Oracle support in version 6 it is not entirely true. Depending on your point of view we dropped Oracle support the moment I was forced to ask Don "Hey Don, I made a change in core, committed the Oracle part, could you test it please". In Version 6 we will most likely not bother to write the -oracle.xql files anymore, unless we have an easy way of testing them. We are getting new employees on board, and having them learn Oracle syntax despite the fact that they are not going to use it in their daily work is a little bit mute. So I would have to do the testing for Oracle for all our commits and trust me, I have better things to do as well.

And note, we are only talking about core packages here. With other packages we have releases of packages, maturity level and the sudden drop of support for one or the other database. Take project manager as an example. In 5.2 the project manager version works with Oracle, thanks to the efforts of Janine who needed it for one of their clients. Before she went down the road we started enhancing the HEAD version of project-manager without writing or testing any Oracle code, because the code base we started from did not work on oracle. To make things easy though, we usually commit PostgreSQL specific stuff in seperate .xql files and do not store SQL code in .tcl files (and yes, I said usually for a reason, we are not perfect in this).

I am sorry that my comment started this whole discussion as I think the resources could be put into use much better e.g.

  • Writing a new developer guide on how to make sure the quality of the commits adheres to the levels we want. I would help in writing one, though not sure if I'm the best suited person given my personal history in this area 😊.
  • Training manual on how to write tclwebtests. I still have not much of a clue here either (which probably puts me clearly in the "hobbist" group Simon talked about).
  • setting up a test server for Oracle and postgres with public access so people could test their commits immediately on a neutral environment (and I added postgres, because if someone writes in Oracle he should not be forced to maintain a postgres installation either).
  • Come up with a clear standard on commits, releases and maturity levels. There has been discussion on this topic, where I voiced my point that you should commit early and often, but be more strict (with regards to quality) once you release and give a maturity level. But a decision and consensus on how we want to achieve the goal (prevent code duplication, allow preview of what people worked on, make it easy for them to commit their work, instead of having it remain on their computers as they don't have time to clean it up, test and release it) never was reached (or I missed it...).
  • Clean up the code of the packages. Mark them with clear maturity levels and release them once tested. I would like to reduce packages that people want to install because they think they work, though they are actually only meant for developers.