Code review comment for lp://staging/~akretion-team/openobject-server/openobject-server_5.0_patches

Guys,

We all want unit tests, sure. The current one at test.openerpobject.com are
not enough yet, that sure. But nvertheless WE CAN TEST IT OURSELVES, even if
it's more work, I think for exceptionnal things it's valid too. Again, by
knowing OpenERP quite a bite, I affirm that it's quite easy to ensure we
pass in every line changes I made during field_view_get calls (calling
views) and translation opérations. There is no need to tweak any very
special business workflow to do that, we just need to test the regular
things, and more importantly call all the views we can, those will alone
call all those lines, I think others can confirm.

Christophe, I perfectly agree that in production you can use some oldy
Debian or Ubuntu, even if not all customer will like it (remember, lot's of
customers are very small company that already have trouble using Linux,
asking them to use Debian or not the easiest Ubuntu they have on their
Desktop is not appealing to them).
Now, 50% of the reason I want this applied, is US DEVELOPERS/INTEGRATORS and
the all the new potential developpers OpenERP can attract to pound in behind
the tests and contributions. Lot's of us/them will want to use a reasonably
recent Ubuntu distro on their Desktop, and lot's of them will have only one
laptop. By sayingt fuck to them for Hardy, we are certainly loosing lot's of
them for Openbravo, Tryton and god knows what other package.

5.2 might happen in late December (BTW, I'm concerned because I find this
quite soon and the community effort has not been coordinated yet, lot's of
required refactoring might not be undertaken unfortunately), Just like me,
you know perfectly that the slow one year dev cylces Tiny choosed make that
5.2 will be usable in prod only around February at best, because it will
start with lot's of bugs as usual. The more integrators know OpenERP/Tiny,
the more cautious they are to the new version that are developped in the
Indian dark during one year, receiving almost no test at all. Last year,
Smile participated to the 5.0 dev effort, deploying it by December 2008
already, we had to tackle A LOT of bugs with little reward because stability
happened only around March 2009. Meanwhile, I remember the experienced
CampToCamp guys laughing at my face, saying that they will stat testing 5.0
only by February 2009, because they couldn't afford loosing that much time
with bugs/regressions. So my point is that yes, we should take care of 5.2
right now, but it won't be usable any time soon. And in those coming 6
months, I think OpenERP will just suffer a lot in term of image if they
don't have an easy way to install a dev env of OpenERP easily enough on the
soon most popular Linux distro.

Moreover, as Numérigraphe and others say,
doing nothing WILL NOT result in increased stability. It will result in
Debian/Ubuntu dropping recent OpenERP support and offer only very alpha
unstable packages of OpenERP (like 5.0.3) or port it using very dubious
debdiff files Debian/Ubuntu maintainer have no skill to check, meaning bugs
WILL occur on Ubuntu distro; and as I said, this won't solve the dev
community issue, but rather frighten those devs.

Finally, if you look carefully at that branch, it's no my own experimental
work, it's just a careful backport of 3 selected trunk revisions (1
principal, 2 fixes). I couldn't find out because merges on the trunk branch
have not been handled with care (considering the bzr lag here over git; bzr
still loose the source branch during such partial merges, so I milit for
very explicit merge commit messages meanwhile), but those changes were from
partners (Almacom or Activity Solutions, can't remember, that use it in prod
too because they couldn't accept the old deprecated libs).
So this work is already included in 5.2, that's just a careful backport of
it. Also notice that if it were merged, it would also by the way make
posting bugfixes betwen 5.0 and trunk easier for Tiny devs. By analysing the
trunk branch, you'll see for instance that rev #1845 revision or oepnerp
trunk I wanted to merged had its conflict not resolved properly by Tiny,
only weeks later thy fixed it in #1857. This proves having such a gap
between trunk and 5.0 in the critical early debug phase might rather result
in a lot more bugs/regressions in 5.2. By biting the bullet now and applying
this patch, we would avoid some of them at not stability cost I think if we
test this all properly.

Right, I think I said all I could about it. It will be up to Tiny
ultimately.

Regards

On Thu, Oct 29, 2009 at 7:53 AM, Nicolas Évrard <email address hidden>wrote:

> We are not sure about the fate of this change because of the lack of
> unittests.
>
> A good test set (ie one that test every feature) would prove that switching
> from a library to another does not have an impact on the overall stability
> of openerp.
> --
>
> https://code.launchpad.net/~akretion-team/openobject-server/openobject-server_5.0_patches/+merge/14112
> You proposed
> lp:~akretion-team/openobject-server/openobject-server_5.0_patches for
> merging.
>