Posted by
David E Jones-2 on
Jul 24, 2006; 6:24pm
URL: http://ofbiz.116.s1.nabble.com/Re-Tasks-for-a-release-tp170046p170064.html
Si Chen wrote:
> Hi everybody -
>
> I'm really glad we will be doing a release for OFBIZ again. Here are a
> things I would really like to see -
[snip]
> 3. Separately, there are some production-readiness issues which we
> should address prior to a release. For example, there was a typecasting
> issue for the minilang field-to-field and a PostgreSQL bytea/oid issue
> that conflicted with Derby which were never satisfactorily resolved. I
> think if we're going to put out a release and tell our users "this is
> ready for production use", we should address those.
>
> 4. Also, has the new Geronimo transaction manager been fully tested?
> Are the reports of transaction time out issues real?
With the branch process I mentioned in the other email these issues don't matter so much.
Yes, we want to have something as close to production-ready as possible, but OFBiz is a big system that supports a really wide variety of lower lever software to interact with, so there is no way we can guarantee (unless someone has a bunch of money socked away that they want to dedicate to a testing lab...) that OFBiz will work OOTB with all combinations of infrastructure software without subtle configuration and/or code changes specific to a circumstance.
So, while these two issues are worth keeping an eye on and fixing when we can, I don't think either is a show-stopper for a release, even a "production stable" release.
For both of these it may be that those who are able to fix such things don't have the resources to do so now, but any reasonable size deployment team usually has people around who can. Also, such things are often easier to fix for a specific circumstance than something that is meant to work in a wide variety of cases, which is the case with the Postgres issue. With a little creativity and experience it is possible to fix in a very widely applicable way any such issue and not have any problems with Derby or Postgres, but with no resources to do so... the best we can do is get a release out and attract more resources to the community...
On the Geronimo issue: I still haven't seen reports of anything that seems to be a core issue with Geronimo. People report errors all the time that are caused by things like timeouts and such or a lower level error that causes rollback-only to be set and these manifest higher up as transaction errors, but the details are in the logs. So far I haven't seen any clear definition of a problem with Geronimo. That doesn't mean there isn't one, it just means that from what I've seen on the lists it hasn't been isolated yet (ie seen by someone who can recognize it for what it is and distinguish between a real Geronimo problem and a simple timeout or other error that caused the transaction error).
-David