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