openerp-expert-framework team mailing list archive

["P. Christeas" <xrg@xxxxxxxxxxx>]

On Wednesday 09 February 2011, Raphaël Valyi wrote:
> 2011/2/9 P. Christeas <xrg@xxxxxxxxxxx>
> 
> Still because of the current branch organization, specially with the
> extra-addons which are mostly authored by independent third parties, we
> have this issue here with bzr and the extra addons.
> Or do I miss something?
you miss that bzr is incomplete. And the fact that you assume one "trunk" is 
enough for everybody (that's the svn way, I refer to).

> 
> Sorry, but what has it do do with "users"? I'm the guy that make OpenERP
> work for those companies, users will not see if I'm using a VCS under the
> hood, they will only see if it works or not.
Such an installation requires manual attention, doesn't it. You could get away 
with 5-10 (at most) instances, but above that you'll find spending all your 
time looking at 'bzr status' commands.

> I don't know how you do, but we all see those critical bugs passing on the
> bug tracker. In average, every OpenERP project I do should face around 5
> blocker bugs.
I can find you more, if you want ;)

> In the tracker we are kindly told by your team "please update your code"
> What is then the smart way to "update your code" if you don't use bzr?
> Apply every patch manually? Same things for translations?
> Honestly, our deployments are all done using bzr, so a single bzr revno or
> bzr diff can tell you about the stats of the system: custom patch,
> backports etc...
> How do you do else?
Packages, custom ones. (see below)

>..
>
> Take the osv_memory hardocded limit bug. 
For the record. I believe your patch was at the wrong place. It should have 
been at 'stock.partial.picking', not the full orm_memory class. In other news, 
I had spent some time creating a framework for dimensioning:
http://git.hellug.gr/?p=xrg/openobject-server;a=commit;h=7b6e63a769d83b1a0
http://git.hellug.gr/?p=xrg/openobject-server;a=commit;h=e2355f3e746f4633197
http://git.hellug.gr/?p=xrg/openobject-addons;a=commit;h=94e80e23bc9c4e48c6

> xrg, seriously, I'm very curious what do you suggest that beat using a bzr
> branch for real life deployments of OpenERP.
> 
> So again, if others have suggestion on how to migrate say an server-trunk
> to a server-6.0 regular branch with same numbering without having to
> re-download it all, I take it. Bandwith is precious here...

The flow I've been using is:
take an arbitrary point in the code history, one point that I'm confident it is 
stable enough and contains the fixes I want. Mark it and do all the testing I 
can think of (incuding real-life scenaria).
Build that revision into packages, using a repeatable script that does 
everything automatically. I don't need to prepare anything, just issue the 
"rpmbuild -ba openerp.spec" command and I'm done.
Install the packages into a "testing" machine. Not the development one, 
because that may be affected by current hacks.
If I'm happy with the results, deploy to production. These packages get 
installed cleanly and automatically, contain minimal code (because they're 
split into server, modules etc) and have implicit version control, so that I 
know what each production machine runs. These (production) machines will 
merely get the "updates available" notice as soon as I publish the packages. 
They will (by default) log in their syslog the fact that packages got upgraded 
(at one case, I had a monitoring system automatically triggering the update).
This procedure was designed to accomodate custom fixes, too, through special 
"series" of the packages. But, at every case, it was easy for me to keep a 
total track of what revisions + "patches" each production would run.

http://members.hellug.gr/xrg/

The reaction so far has been "We don't need that, we will just copy the files 
to the customer".



-- 
Say NO to spam and viruses. Stop using Microsoft Windows!