Hello Albert, The current situation is that most integrators that have a critic mass have there own branch of OpenERP with their own fixes instead of the Tiny branch: example include: - Syleam - CampToCamp - Almacom - Hellug - Chricar? - Axelor/Tiny themselves with branches like https://code.launchpad.net/~nch-openerp/openobject-server/stable_report ? - now Taktik as they just announced it here http://devteam.taktik.be/index.php?/archives/14-Taktik-objectives-for-OpenERP.html Well can't list them all. There is also that parallel report engine: https://launchpad.net/report-openoffice ...
I think this mostly results from the past instabilities or wildcat changes like the report engine swap or the fiscal position signature change or the huge need for non backward compatible patches or sometimes simply to get a decent localization (trunk is synch'ed daily, 5.0 isn't). But this is far from optimum because: - everybody does redundant effort on his own branch - at the bottom line, everybody suffer double when they should migrate to new OpenERP version because Tiny may or may not have include their patch - modules continue to be developed on non fined grained/reusable API and a lot of effort is wasted in building such modules that will not be reusable/compatible but will instead just loose the integrator and general public in a flood of low quality modules. Currently modules only enter but are never officially deprecated, this doesn't scale. - small integrators like us cannot even afford maintaining their own branch - not to speak about the optimistic folks that go without an integrator or try to use Odoo and will have none of those patches Because of all this, I think this makes sense to have a power user/partner branch that would be collectively maintained by the serious partners/power users. That would at least mutualize that maintenance branch. On that branch/project we could have our own release/sprint schedule/bug planning. Now I see 3 issues with this: 1) it's pointless if at the end Tiny doesn't include the patches like the merge proposals in 5.2 being hardly considered currently... 2) I'm not sure it's good on the marketing point of view because it tends to put under question the official stable branch which for instance is really the contrary that Tiny is trying to build with Odoo and the quality image we would all like to show to our customer. For instance this wouldn't have help the Tiny fundraise we would all benefit by an increased OpenERP competitiveness. Having the official branch lagging behind and having to tell well you know Tiny have their own customer and they can't afford following the bugfix/innovation rhythm sucks in term of product readability for the average user. 3) what would be the common basis for such a branch? I assume there is no big reason to fork right? I mean I doubt lot's of folk think Tiny doesn't have the right political vision AND some alternative people would have a better legitimity along with a credible capacity to carry a fork (I recall Tiny is able to tackle more than 10 bugs/day thanks to their established India infrastructure, who else can do that?) AND this is different from Tryton, right? Then we are speaking about a collectively maintained branch, not a fork. Like Unladen Swallow for Python if you like. But there is no Google driving force here, not even an OpenERP foundation. So what would be the common denominator of that branch? Well there are lot's of possibilities. For me the simplest would be that definition: "This branch X is last stable OpenERP + any backport from trunk that a serious partner/power user entitled to maintain it for a real customer (eg money)" for instance if one such a 5.0.x branch somebody like CampToCamp would have assumed a backport something like for the multi-currency rounding writeoff issue, I guess we would have been a lot of partner to assume it too, believing that it might not be optimum, it's already much better than the current situation. On his side, say CampToCamp would anyway have his customer patched on their own branch because they can't afford that kind of bug. For CampToCamp, it may have a little extra cost to patch the common branch X with enough quality of course BUT, I'm pretty sure anyone understand that the collective benefit from having the patches from the other partners largely outweighs that little extra cost. For sure, instead of everybody having their own branch, mutualizing that effort this way would be already a huge win. Now, this doesn't solve too much the: will Tiny merge the proposed patches in next stable issue? I defined X as a branch containing ONLY BACKPORTS, it means that it should have been merged once in trunk at least so be accepted in X. So it doesn't remove the Tiny bottleneck at all here. Still, eventually Tiny might think such a branch would be so good an so mature that it can save time for Tiny using it in their own projects and thus allocate that saving to analyzing better the merge proposals, An other source saving for Tiny is that, they could then rely on partner for a larger part of their R&D effort, meaning they can carry less here and re-allocate resources to the branch merge proposals. Partner on their side would be less reluctant to invest in R&D because they would have more clue their innovation/bugfix will be included and spend much less time fighting bugs that result from questionnable design over and over. If instead we say branch X can accepts patches that are not backports, then we open the door to any abuse/endless debates and risk that lots of folk follow a path that will diverge from the next stable, which is something very risky for everybody. Now for me branch X makes more sense at the end of a release cycle, when you really can't afford jumpstarting to next stable because it will be to much instable the next 6 months and when on the contrary Tiny can't afford making backward incompatible change on the stable because they wouldn't be able to migrate their own customer to it or would be bad in term of stability image. I think we are in a situation where ambitious integrators will soon be able to jumpstart on 5.2 (if next project in like 2 weeks is big we could do it), because we think 5.2 will because stable enough within the scope of our project (at least more than the current stable on the scope we are interested in) and we really need the fix/innovation to get merged instead of having to wait one more year (if the freeze has not enough fix) with limited competitive integration costs and thus a harder market. So I'm not sure branch X is the smartest solution for now, but let's say I gave the idea. For now I hope Tiny will just: - create the required milestones - analyse the pending merge proposals - interact with experts here. I recall that Tiny themselves wanted those expert lists. and 2 weeks ago Fabien promised me there will be something from Tiny interacting here. Well I assume they got flooded once again, let's wait. Honestly there have been some improvements and reasons to hope: - there have been a real rush test of 5.0.7 against regression during December so I think 5.0.7 might be the most regression free OpenERP release ever - regressions and critical bugs have been flagged on 5.0.7 milestone and priorities have been somewhat enforced even if very far from strict. - this list may not have the feedback from Tiny yet, it already allows expert vision exchange and quick bug evaluation like it has never been done before. - slowly but surely, Tiny moves. For instance last week, there were more than 10 people waiting for production expert team approval. Today they are finally in... Now, just like you Albert, I think OpenERP should really move its ass to fix its hottest issues because the proprietary competition on short term visible costs is tough and getting harder everyday. Yes, customers choosing proprietary ERP's will probably be in extremely bad shape when their ERP will be abandoned/bought in 5 years and when they will need to migrate without any connectivity nor communit. But guess what, the average customer is unlearned and like a lemming, he will always fall into http://sevenlakessoftware.com/information/COERPCourse/ so that's why we need an obvious short term competitivity too. Failing to address things like rounding, basic module compat, or decent widget ergonomy for 5.2 and having to wait for 2012 is not even an option. BTW, we limited especially to avoid bloating Tiny with non qualified requests/suggestions. If Tiny doesn't read it anyway, it doesn't make sense to limit the audience so drastically as they required it. Thoughts? Raphaël Valyi http://www.akretion.com 2010/1/20 Albert Cervera i Areny <alb...@nan-tic.com> > A Dimecres, 20 de gener de 2010, Raphaël Valyi va escriure: > > Hello, > > > > The community doesn't spend a lot of time currently on bug planning > because > > we still can't do it efficiently unless you do what I list here: > > snip > > > I talked about that with Fabien, Quentin and Christophe and we all agreed > > that we need some scheduled released at least (like one per month or per > 2 > > months, this is up to you but I personnaly prefer one per months to make > > users benefit the more possible bugfix), so why is that not done? Can't > you > > do it? We community have no admin rights neither authority to do the > > schedule nor the releases. > > Maybe it would be better for tiny and the community to have one > openerp-server > and openerp-addons branches owned by community-leaders or another > restricted > group that would do their own priorization and schedules? I'm not sure, > about > this, but sometimes not being able to fix some things really slows things > down. We currently can get faster (better?) feedback from these new mailing > lists than from Tiny (they have their resources and priorities which I > understand). > > -- > Albert Cervera i Areny > http://www.NaN-tic.com > Mòbil: +34 669 40 40 18 >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community-leaders Post to : openerp-community-leaders@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community-leaders More help : https://help.launchpad.net/ListHelp
