openerp-community team mailing list archive

[Nhomar Hernández <nhomar@xxxxxxxxx>]

Hello.

I really prefer a tested policy than an "experimental" option.
I want sleep better than pray not brake something everytime we make some
autopull.

I am  agreed with Oliver too! change schema bring a lot of problems, and
sometimes it is better dedicate a little extra time to solve without change
the core.

We have several examples where "supose" change is simple other workflow
brake things silently or loudly.

It means, I understand with no experience, It is difficult to see, but one
time you know deeper OpenERP framework almost (almost because there are
case wher it is not true) almost everything can be fixed with an extra
module.

Even it is one of the reasons we don't use OCB for our internal propose,
and even we have some pre-merges that passed the "Internal quarantine" and
can be merged in OCB, but expend time to see and become them mergeable is
too high.

May be we should reconsider this, in this way we will be really able to
make the merge if we are everybody agreed in the same policy.

 Remember always _before_ ask for something "Community" is not an "Agnostic
Entity" which will solve all our problems, we are people with priorities
and compromises "Everybody is in the same situation", then If we don't take
the approach from a "tested policy" we will load _always_ to somebody else
with the extra job.

My 2 cents:

PS: All this is asking "Make mergeable" the ocb branches, in this way we
can make an MP with every pre-merge from our OPW and Community bugs, but if
it is not in our roadmap and it will bring more than a command (because the
review is done already in our internal process) it is so expensive to us,
and I really think to the majority of us.

In speanish we say: "The medicine is worth that the sickness" if we brake
the stable policy.


2013/10/25 Ronald Portier <ronald@xxxxxxxx>

> Personally I think that if the official branches are made less strict,
> in the sense that they accept database changes needed to resolve bugs,
> then there should be no problem to proceed along the lines proposed by
> Olivier.
>
> I think most people who contribute features and fixes to the stable
> branches are well aware of the need to avoid database changes wherever
> possible.
>
> But I fear that having an "experimental" OCB branch in the official
> projects, alongside a "conservative" branch, will just make things
> complicated.
>
> Experiments can (and should) go into all kind of directions. An
> officially approved experimental branch sounds a little bit like a
> contradictio in terminis to me.
>
> Just some thoughts that occured to me reading the discussion....
>
> Kind regards, Ronald
>
> Olivier Dony schreef op 25-10-13 18:09:
> > On 2013-10-25 16:44, Stefan wrote:
> >> On 10/25/2013 04:21 PM, Olivier Dony wrote:
> >>>
> >>> Only a few obstacles remain before this can become a reality:
> >>> 1/ The OCB branches would need to be relocated under the official
> >>> projects
> >>> 2/ The OCB branch management process needs to be adapted accordingly
> >>> 3/ Compliance with the OpenERP stable policy [2] should be added to
> >>> the review checklist for OCB branches, and the current branches
> >>> reviewed in this light
> >>> 4/ (Option) In order to allow for some degree of non-compliant
> >>> changes, an "experimental" version of the OCB branches could be
> >>> forked. It would not be recommended for production and not merged back
> >>> into the official distribution.
> >>>
> >>> Stefan, does this accurately describe the options we discussed?
> >>>
> >>
> >> Thanks Olivier, for highlighting your intentions in this direction
> again.
> >>
> >> My personal gripe is with [3]. I think having an 'unstable' series that
> >> does allow the occasional new field to percolate through is a major
> >> attraction to OCB. It must be the reason that I remember our
> >> conversation at the community days slightly differently: keep the OCB
> >> branch in its current form with its current policy, but using technical
> >> means to mark merged changes that conform to the OpenERP stable policy
> >> so that you can easily feed back bugfixes from OCB to the official
> >> series. We have not yet had the chance to work this out.
> >
> > I understand that you may see non-compliant changes as a desirable
> > feature of the OCB branches. And that does not preclude having them in
> > the official projects and tracking them in runbot as well, of course!
> >
> > Unfortunately I would have the same problem as Lionel if we can't simply
> > merge the branches after reviewing the diff. If the process becomes too
> > time-consuming or technically impractical for us we won't be able to
> > dedicate resources to do it. It also seems that cherry-picking commits
> > will increase the chance of conflicts when you auto-merge those commits
> > back into the OCB branches. That's one of the reasons why I thought we
> > had discussed the creation of 2 versions of the OCB branches:
> > - one stable version very close to the official branches (i.e. a few
> > commits ahead)
> > - one experimental version with extra commits for technical people who
> > know exactly what they're doing and don't mind diverging from the
> > official version.
> >
> > Note that you could perhaps modify your OCB scripts to automatically
> > maintain the "stable OCB branch" based on the "experimental" one with
> > some commit tags, but that may be overkill.
> >
> > On a related subject, I was also wondering about the future of those
> > divergences from the official version once a new OpenERP release is out.
> > Based on OpenERP's architecture I imagine the easiest would be to move
> > them to appropriate community modules?
> >
> >
> >> As for hosting the series branches under openobject-addons, that would
> >> be great. I'll gladly give up the separate projects for the ease of
> >> having to prepare only a single branch and MP for each fix.
> >
> > Great!
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openerp-community
> > Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openerp-community
> > More help   : https://help.launchpad.net/ListHelp
>
> --
> Met vriendelijke groet / Kind regards,
>
> Ronald Portier
>  /"\
>  \ /
>   X
>  / \ ASCII Ribbon campaign against HTML E-Mail
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>



-- 
--------------------
Saludos Cordiales

Nhomar G. Hernandez M.
+58-414-4110269
Skype: nhomar00
Web-Blog: http://geronimo.com.ve
Servicios IT: http://vauxoo.com
Linux-Counter: 467724
Correos:
nhomar@xxxxxxxxxxxxxx
nhomar@xxxxxxxxxx
twitter @nhomar