openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

On Fri, Feb 26, 2010 at 5:13 AM, Sebastien LANGE
<sebastien.lange@xxxxxxxxx>wrote:

> Hello,
>
> For one of our customer, we've develop the multi-company with Tiny. But
> we've decided to code in next version, actually the trunk because this
> version should be freeze in end of december.
>
> Since January, Tiny developp a lot of new features and now we have a
> serious problem with our customer.
>
> This client has 9 big company and change all their existing software by
> OpenERP and now ask me when this version will be freeze. This same customer
> purchased a maintenance contract editor where most bugs are not corrected by
> the editor and we are therefore obliged to help correct them.
> The deadline for our customer is April for using OpenERP in production.
>
> My question, when this next version will be really freeze ?
>

Not sure you will appreciate, but from Stephane Wirtel:
"two or three months, but there is a milestone on launchpad. "
http://www.openobject.com/forum/viewtopic.php?p=52079#52079

For us that's a mixed feeling: it's really delayed compared to the December
Tiny told you. Now it gives time to have enough stuff in (had they freezed
in December there was almost nothing important other than cosmetic new over
5.2)...
We do have the opportunity to jump-start on 5.2 right now. But just like
you, wee need a clear visibility. When Tiny says 3 months, well it
incentives us to wait for a few more weeks. That's bad cause if we do so,
then we don't help as we could, but we aren't kamikaze either.

I think this totally demonstrates how pointless the 1 year release policy
is: releases are not stable at the date announced cause nobody else than a
few Tiny employees worked on it. The first to jump on it, suffer from it
rather than being rewarded for their efforts...
And it's too long before the next release for integrators to be able to test
and contribute features/refactoring.


On our side, what would would like in for 5.2:

************* critical: *************

1) those merges for better extensibility of some modules, Python portability
(at least partial for 5.2 and better later; one step at a time):
https://code.launchpad.net/~akretion-team/openobject-addons/addons-mxdatetime-free/+merge/20342
https://code.launchpad.net/~akretion-team/openobject-addons/extensible-inventory/+merge/20293
https://code.launchpad.net/~rvalyi/openobject-addons/extensible-mrp/+merge/20294

2) We also have Sebastien Beau working right now on that one:
https://blueprints.launchpad.net/openobject-addons/+spec/refactor-old-wizards-on-osv-memory
We are trying to refactor the most likely used wizards in osv_memory, that
is:
- invoice on picking
- partial picking
- pay invoice
and optionally:
- group purchase orders
- mass reconciliations
We will try to come up with a proof of concept tonight and count on the
community to help us tackle that short list.

3) We also need at least decent extension points to be able to re-factor the
tax_include modules properly. Ideally those would be re-factored in the
core. Whether it's possible or not pretty much depends on how important Tiny
judge this issue. But Brazilian or US localization really need that in a way
that work and plays nice with other modules (so is there a point OpenERP SA
open a US office if they are unable to deal with US fiscal rules properly
for the whole life of 5.2?)

4) enforce the XML/RPC protocol with error codes:
blueprints.launchpad.net/openobject-server/+spec/xmlrpc-should-return-int-faultcodes
(would
avoid the burden to force each connector to have to parse response strings)


 ************* Not critical but would be cool to have (would cost little and
help a ton, but no need to drag 5.2 for that, specially if release cycle
becomes 6 months): *************

5) search_read method like Tryton (would dramatically speed up clients and
also cross languages WS calls)

6) JSON connector (more pure JS possibilities in the browser; faster)

7) WSGI server compliance (for better portability, on J2EE servers for
instance, at least as a proof of concept first)

8) YAML data loading (given that OpenERP SA is committed to it already,
otherwise not that a priority)


************* Desperate dream list for a better usability (it all depends on
how Tiny spots those issues, but I don't want to drag 5.2 specifically for
that): *************

9) one2many management in web client like the GTK client without the need to
create resources one by ones

10) Dynamic domain working on selection widget too:
https://blueprints.launchpad.net/openobject-server/+spec/dynamic-domain-on-selection-widget

11) symmetric of forms passing parent form params, but for changing them
this time:
https://blueprints.launchpad.net/openobject-server/+spec/form-parent-field-update-on-change

12) option on many2one widget to allow one-click creation without the need
to click through the search popup (combined with 13), could be really more
user-friendly)

13) Confirmation dialog pattern: currently, you don't have in OpenERP the
option to click to do an action, then the server answers you blabla are you
sure? YES | NO
So you would have the option to cancel or assume your action. This is a very
commonly requested feature and very classical. Customer often want it and it
sucks we have to explain them OpenObject doesn't allow that yet.


NB: I'm here talking essentially about features that need to
change/enrich the core server or addons. Of course lot's of other important
features could be contributed. But if they could be contributed as extra
modules, then they should not delay 5.2 as they could be added afterwards
without breaking any backward compatibility/API.


What do you guys think of that list? Have you solutions or are you ready to
help on some items?



Raphaël Valyi
http://www.akretion.com

>
>