Hello Alan, I think you missed my point. I don't want to run old 5.0.0, I just want to be able to run any 5.0.x last release or branch revision without Ubuntu folks to need to elaborate patches on their own. Just like any integrator, I'm working with head 5.0 revision and actively testing it and improving it. If only Tiny works on head revisions, this is very risky and doesn't scale to the development power that is required to turn OpenERP a major ERP solution.
Why not use 5.0.5. Well, I integrated OpenERP several times, 5.0.5 has lots of critical issues, for instance SQL injections issues + privilege escalation (bug is not public because it's a security issue but it's present). v 5.0.6 has a critical bug with amount due in invoices. Experience show that for a reasonable scope in production, all release still have critical bugs, the only working path is stabilizing some version and then back-porting manually patches for the most critical bugs you'll encounter. This is no coincidence if lot's of integrators rather deploy their own branches rather than the official """stable""" releases. Nonetheless I think it's good to have a Ubuntu packages of Tiny official releases. OpenERP is maturing quickly. Those package are already good to discover OpenERP on Ubuntu and no doubt they will be production ready in 6 months or so. But in general we need a suitable solution for the serious people like us that really deploy OpenERP for real and can't afford random regressions (even if less frequent fortunately), that's why I propose biting the bullet and fix XML compat things once for all, on a wider scope even than the Ubuntu distro scope alone. "If there are critical bugs in 5.0.5 or 5.0.6 then surely it would be better to fix them and move forward than to backport code fragments to an older release?" -> Most of the critical issues I think are fixed indeed with no major regression I know (so 5.0.7 promiss to be good so far but we never know). The point is that we need to streamline the 5.0.x releases/head revision to deployement cycles, avoiding dubious debdiff that will solve only the Ubuntu package case with major lags and risks and similar works on other distro... Basically my patch is similar to your debdiff, except that I've been very careful when tracking orgininal etree commits in trunk branch, commit by commit to make sure we never miss some later fix (it's easy, in the commit history, Tiny themselves mad a mistake when resolving conflicts). How would Ubuntu maintainers maintain themselves those debdiff better having virtually no OpenERP knowledge? Best regards, Regards -- orm.py needs to use libxml2 rather than pyxml https://bugs.launchpad.net/bugs/429519 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
