← Back to team overview

openerp-expert-framework team mailing list archive

Re: do we really need lp:openobject-addons/extra-6.0 and lp:openobject-addons/extra-trunk ? IMHO: NO

 

2011/2/9 P. Christeas <xrg@xxxxxxxxxxx>

> On Wednesday 09 February 2011, you wrote:
> > Also an other problem of multiplying the branches is that currently we
> have
> > no tool to port the bzr history when porting a module from one branch to
> > annother, this is not encouraging contributors to use those branchs as
> the
> > history of who made what is likely to be lost when switching to the new
> > branch, this also looses lot's of useful meta-information about why line
> X
> > is this way where you  could know that with bzr-annotate if history was
> > here...
> >...
> That's typical short-comings of svn [1]
>

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?


>
> > I cannot really imagine re-download 4 branches at all my customer
> > deployments and then re-apply the production patches manually...
> > Anything better?
>
> I wouldn't ever install VCS-related versions at any production site. End
> users
> are not developers.
>

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.
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.
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?
I agree, OpenERP is the first open source software ever I had to use an
install from src + a VCS even on production installation. But I also tried
the other way, a "release", but I'm very curious how you suggest you do then
to keep with the patch flow, including all blockers any project has
currently. Or do you suggest deploying the broken releases? Also don't
forget that the concept of release was really loose at OpenERP till
recently, v5 releases could happen or not randomly after 2 week or after 6
months, is that the 'formalized procedure" you suggest we use instead?

Take the osv_memory hardocded limit bug. I had to patch it for my customer
be able to process their pickings. How will I figure out I made that patch
on their server in 6 months if I wasn't using bzr vs specific OpenERP
versions? If you agree then that a VCS is good, why just not use a bzr
branch?

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...


-- 
Raphaël Valyi
Founder and consultant
+55 21 3010 9965
www.akretion.com

Follow ups

References