Re: Tasks for a release
Posted by David E Jones-2 on Jul 24, 2006; 10:01pm
URL: http://ofbiz.116.s1.nabble.com/Re-Tasks-for-a-release-tp170046p170062.html
Si Chen wrote:
> David,
>
> Without coordinating a feature freeze between the major contributors, it
> would be very very difficult, especially for less experienced
> "volunteers", to maintain the release branches and fix the bugs. From
> my personal experience trying to create the opentaps releases, a good
> release can only be created if the original version is reasonably stable
> and if the core developers significantly support the effort by helping
> to push the bug fixes from trunk to the release branch.
So, your hope in doing a feature freeze is to get more people involved with bug fixing and maintenance of the releases?
It's an interesting thought, but I think it might back-fire more than help. In other words, I'm guessing it would have an effect of reducing contributions for advancement of new features without increasing contributions for bug fixing and maintenance.
In general we're constrained somewhat by the natural forces (ie contracts, employers, free-time + interest, etc) that drive things into the project. Based on that my thoughts are centered around facilitating contribution and I believe that if we do a good job of this then it will drive new stuff for improvements as well as fixes.
> On the issue of stability:
>
> 1. I propose that we put this
> http://jira.undersunconsulting.com/browse/OFBIZ-500 back into the main
> code base. It addressed a typecast issue with field-to-field.
I'll try to take a look at this sometime this week. With any luck there will be some slow time at the show... ;)
> 2. I think we should take a vote: how many people would like to keep
> current code "as is", so the "OID" data type (used for storing images
> and content) works with Derby and not PostgreSQL, versus making a change
> which would make it work with PostgreSQL and not Derby?
I'm having a hard time seeing a reason why we have to vote for supporting one and breaking the other.
At worst we should have a configuration parameter (like an attribute on the datasource element in the entityengine.xml file).
At best we should look into a REAL solution that works well for both and may address other current or potential issues with other databases.
My opinion right now is that whatever the case we should not break Derby to make things easier for Postgres... The OOTB settings use Derby and that should work properly as the test bed as well as for demoing.
I'll take a look at this if I can, but proper testing and playing with JDBC code changes would require at least half a day for me to set things up and play around and expect to dig deep enough to find a good solution. I can't commit to that for at least the next 2-3 weeks.
> 3. I'll just keep my fingers crossed about the Geronimo transactions
> manager then.
Yeah, until we find more information (ie good test cases for problems or a good error message or something) there isn't much we can do...
-David
URL: http://ofbiz.116.s1.nabble.com/Re-Tasks-for-a-release-tp170046p170062.html
Si Chen wrote:
> David,
>
> Without coordinating a feature freeze between the major contributors, it
> would be very very difficult, especially for less experienced
> "volunteers", to maintain the release branches and fix the bugs. From
> my personal experience trying to create the opentaps releases, a good
> release can only be created if the original version is reasonably stable
> and if the core developers significantly support the effort by helping
> to push the bug fixes from trunk to the release branch.
So, your hope in doing a feature freeze is to get more people involved with bug fixing and maintenance of the releases?
It's an interesting thought, but I think it might back-fire more than help. In other words, I'm guessing it would have an effect of reducing contributions for advancement of new features without increasing contributions for bug fixing and maintenance.
In general we're constrained somewhat by the natural forces (ie contracts, employers, free-time + interest, etc) that drive things into the project. Based on that my thoughts are centered around facilitating contribution and I believe that if we do a good job of this then it will drive new stuff for improvements as well as fixes.
> On the issue of stability:
>
> 1. I propose that we put this
> http://jira.undersunconsulting.com/browse/OFBIZ-500 back into the main
> code base. It addressed a typecast issue with field-to-field.
I'll try to take a look at this sometime this week. With any luck there will be some slow time at the show... ;)
> 2. I think we should take a vote: how many people would like to keep
> current code "as is", so the "OID" data type (used for storing images
> and content) works with Derby and not PostgreSQL, versus making a change
> which would make it work with PostgreSQL and not Derby?
I'm having a hard time seeing a reason why we have to vote for supporting one and breaking the other.
At worst we should have a configuration parameter (like an attribute on the datasource element in the entityengine.xml file).
At best we should look into a REAL solution that works well for both and may address other current or potential issues with other databases.
My opinion right now is that whatever the case we should not break Derby to make things easier for Postgres... The OOTB settings use Derby and that should work properly as the test bed as well as for demoing.
I'll take a look at this if I can, but proper testing and playing with JDBC code changes would require at least half a day for me to set things up and play around and expect to dig deep enough to find a good solution. I can't commit to that for at least the next 2-3 weeks.
> 3. I'll just keep my fingers crossed about the Geronimo transactions
> manager then.
Yeah, until we find more information (ie good test cases for problems or a good error message or something) there isn't much we can do...
-David
smime.p7s (4K) | Free forum by Nabble | Edit this page |