openerp-community team mailing list archive

[Fabien Pinckaers <fp@xxxxxxxxxxx>]

Ferdinand,

This is not an issue anymore. The new realease policy fixes this. We don't do anymore cycles like: develop for 9 months, fix during 3 months, then release.

Now, the trunk is stable. Every new feature in trunk goes to minimum 3 code review before being merged in trunk (the developer, its team leader if any, functional useability expert (apr), then another developer not involved in the development).

So, the trunk follows a continuous test and integration code review.

But the thing that improves even more the stability is that: all saas customers, all training attendees and openerp SA are on the trunk. We upgrade them every month.

So, now, the bugs are detected on the trunk, because the trunk is already massively used.

Releasing v8 will not require a huge testing period anymore. And, customers going in production on v8 will have a system that is already used by thousands of users for months.


Sent from my iPhone

On 26 Oct 2013, at 21:17, Ferdinand <office@xxxxxxxxxx> wrote:

> On 2013-10-26 14:36, Ferdinand wrote:
> 
> One other thing comes into my mind.
> OpenERP needs a release cycle with a
> feature freeze - example 7.9
> testing of functionality and migration - 1-2 month
> OpenERP internal
> Partners - migration of key accounts
> release 8.
> many of the problems are usually discovered during the first month after a release and could be dicovered/avoided this way.
> just my 2c
> 
>> On 2013-10-25 18:57, Olivier Dony wrote:
>>> On 2013-10-25 17:43, Mario Arias wrote: 
>>>> Reason to be for OCB branches is that official ones are not "community friendly"... 
>>>> 
>>>>   * Lots of bugs with even corresponding MPs that are rejected and/or ignored... 
>>>>   * Changes needed to really fix a bug that are not accepted because of the "no 
>>>>     change to model", but not fixing is worse... 
>>> 
>>> I strongly disagree with those statements. The OpenERP stable policy is here to protect customers, but OpenERP SA also offers a bugfix guarantee to the customers. So no, the policy can never be an excuse for not fixing a real bug. 
>>> 
>>> I should know because it's my job. I've been dealing with dozens of bug reports and maintenance tickets every single week for the past few years (qualifying reports, reviewing patches, helping to write patches, etc.), and enforcing the policy at the same time. And I've never encountered a *real* bug that we refused to fix, policy or not. If you have, please send me the bug number or maintenance ticket number so I can verify it! 
>> Just some issues in the last time
>> * https://bugs.launchpad.net/openobject-addons/+bug/1242804
>> * httpts://bugs.launchpad.net/openobject-addons/+bug/1212281
>> * https://bugs.launchpad.net/openobject-addons/+bug/1066066
>> 
>> * account-asset was not usable in 6.1 and 7.0 - it's geting fixed in trunk, but that does not help for current installations. 
>> ** https://bugs.launchpad.net/openobject-addons/+bug/1217323
>> ** https://bugs.launchpad.net/openobject-addons/+bug/1241968
>> 
>> And that is exactly the main problem of "communication": 
>> The client has a problem and the partner has to fix it NOW.
>> I would classify these issues as bugs and SA classifies these as wishlist/feature.
>> this also the reason why I am so calm as after 30 years in business I neither want to dispute nor loose my time.
>> 
>>>   
>>> Actually, in most case it only takes a few more minutes of thinking for an OpenERP engineer to find a valid fix that does not violate the stable policy. 
>>> And if we ever come across a bug that *really* requires a model change, we can als is also the reways find alternatives like shipping them as extra auto-install modules. 
>>> 
>>> On the other hand I *have* encountered countless cases of regressions and errors caused by casual changes committed on a stable branch, which is the very reason why the policy is in place. 
>>> 
>>> No, the policy is not designed to make our lives simpler, and it often makes fixing bugs a bit more difficult! But it's definitely worthwhile in order to offer true stability to the customers. Have you tried OpenERP 5.0 at the time where every bugfix was commited directly into the stable branch without any review nor policy?! 
>>> 
>>> And finally no, the great majority of OpenERP deployments are not under the active supervision of OpenERP Partners or competent OpenERP technicians, despite what some people want to believe. Just do the maths! 
>>> 
>>> _______________________________________________ 
>>> Mailing list: https://launchpad.net/~openerp-community 
>>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx 
>>> Unsubscribe : https://launchpad.net/~openerp-community 
>>> More help   : https://help.launchpad.net/ListHelp         
>> 
>> 
>> -- 
>> Ferdinand
>> 
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-community
>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-community
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> -- 
> Ferdinand
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp