Hello folks,
just adding my 2cts: I agree to say that quality should be #1 top priority for OpenERP. Fabien, unluckily, I just discovered at least 2 critical accounting regresison bugs in V5.0.4 (invoice tax cache not refreshed when altering invoice line tax and future aged payment balance crashing); reporting them. So yes, there are very critical regressions from time to time and this really decrease your product competitiveness (given all the time one should take to stabilize a production version). I think that up to 30% (if not 50%) of an OpenERP project cost is currently fighting those regressions daily and testing things that are told to be stable but aren't quite. Customers are not psychologically prepared to that cost and this is a hard educational work on our side to explain them what that 30% tax is. And there are even dumb salesmen that prefer make customers feel happy and make their commission and would not sale that 30% cost, meaning that the workforce suffers it instead or the customer will simply fail their projects (generally the only issue as workforce will rather move over to a new employer quite freely instead). I've just been told that a project Smile lost last year for a partner offering something like 10% less (Smile was already not planning any margin already on that customer at that time), is still not in production while deadline was September 2008; this is just an illustration of what not paying that price might mean... On the contrary, if an OpenERP integration were 30% cheaper with no such regressions, then I think a lot more customers would be able to enjoy it. Still, I've seen a lot of improvement since v4.2. Regressions were still coming almost daily (or every 2/3 days at best) in early 5.0.0.x and we survived it, now it's much better. I'm personally impacted by some regression something like once a week at integration time. I think that the integration server is indeed a great step forward. In my opinion it would be able to catch 20% of currently reported bugs automatically. I hope that it could catch even more as more tests are added to the suite. May be a good policy for that would be: streamline the test writing process and encode new tests for every newly reported critical bug (some fortune 500 companies or very well organized oss projects like JRuby or Rails are building new tests for nearly every bug reported and newly developed features, but I understand perfectly that this would cost Tiny too much for now and paralyze the innovation instead). Now, OpenERP is still a niche market and we all need to make the product more effective. That means that yes, OpenERP needs to evolve, that would not work either to just say, well we will simply stop the innovation to keep it stable. OpenERP should absolutely evolve to become more usable, more robust and more generic. And in my opinion even refactoring is very much required. So overall, I think this is very much a matter of process indeed: - how branches are supposed to work (what are dev and stable branches), more things should be developed outside from stable and merged into stable after deep testing proves it's OK) - tags could be used more aggressively - beta/RC releases could indeed be announced with a bit of advance for testing rather than just released as @nbessic2c told Also I should say I do not really agree with the one release per year policy. Why? 1) Because as there are too many bugs and too many things to evolve, this leads to do too many things in the "stable" branch, exposing users or partner that do not always want to beta-test to regressions. 2) Because if you release a new version only every year, then when do you develop it? You actually tend to develop it like that: 10 months with very low activity and experimental things on trunk branch and 2 months of intense dev at Tiny before new release, then 6 months of intense bug fixing once it's released... The issue is that quality and innovation really comes from the community as well (or should come, else there is almost no benefit of being open source, or at least only half of it). But partners/community have a time window of 3/4 months instead: they can develop a new feature only if the customer they are working for will be able to use it. Meaning that with the 1 release every year policy those Tiny hardly benefit from partner innovation. Worst than that, simple refactoring (which against is very much required) tends not to be done. Indeed in during the 10 months trunk stage it's not done because Tiny doesn't have the resource and because that trunk version is very poorly tested (as nobody uses it and because the test suite is so small). Therefor, it looks like Tiny is not carrying that refactoring because merging all the bugfix from stable version would simply be too hard on a one year re-factored branch. In lots of oss projects I'm following, the policy is rather have much smaller steps and release more often. I personally would prefer 'major' releases every 6 months. Doing that you could: - really release minor (eg fully compatible, no regression) versions between those 6 months, - concentrate API changes, non compatible fixes for the 6 months releases (because they aren't that far away so it's doable) - have partners working for the next release most of the time instead of less then 2 months a year. - have less regression from a major to the next major as they are closer in term of code. Again, just like @gegard said, I think that > the intentions are less of a problem than the practice. and I really recognize Tiny has done what no other oss ERP team did and therefor I continue to congratulate you. I also think that no matter those trouble OpenERP is going to rock the ERP market. I just hope this debate will drive constructive things for the project so it happens sooner. Best regards ------------------------ Raphaël Valyi CEO and OpenERP consultant at http://www.akretion.com -------------------- m2f -------------------- -- http://www.openobject.com/forum/viewtopic.php?p=42358#42358 -------------------- m2f --------------------
_______________________________________________ Tinyerp-users mailing list http://tiny.be/mailman2/listinfo/tinyerp-users
