openerp-community team mailing list archive

[Joël Grand-Guillaume <joel.grandguillaume@xxxxxxxxxxxxxx>]

My mistake... You're right, sorry for that.


Le 5 avr. 2013 à 11:34, Carlos Liébana <carlosliebana@xxxxxxxxx> a écrit :

> Hello Joël,
> 
> Please correct me if I'm wrong, but no 6.1 series there, just 7.
> 
> 
> 2013/4/5 Joël Grand-Guillaume <joel.grandguillaume@xxxxxxxxxxxxxx>
> Dear community members,
> 
> 
> I want to point out that we now have an "official" community branch for 6.1 maintained by the community reviewer team (https://launchpad.net/~openerp-community-reviewer).
> 
> The project urls are:
> - https://launchpad.net/ocb-addons
> - https://launchpad.net/ocb-server
> - https://launchpad.net/ocb-web
> 
> This was launched on the initiative of Stefan (from Therp) and we join our effort here. So we do not use our c2c branches anymore. This should be IMO the community branch to be used by all (sharing effort, bugfixes and review).
> 
> At the time being, here is a little summary (issued by Stefan and approved by all members) of what are the rules for that branch:
> 
> """
> * Branches
> 
> The branches under the 7.0 series should be updated with the latest commits from the official branches every day, using a script that we developed called replay_missing.py [2]. As the name indicates, we started out calling the replay function of the bzr-rewrite plugin but after experiencing serious problems with it we resorted to committing each missing revision as a separate, cherrypicking merge. This seems to be working flawlessly even when tested against modified branches such as the Therp backports. Even so, this must be considered as the most experimental and vulnerable part of the design. When a conflict occurs, manual intervention is the only solution. In time, we will start notifying the members of the ocb team of the results of the nightly merge job. (If you are a low level bzr expert, please tell us if you think that this approach may lead to problems)
> 
> * Bugs and proposals
> 
> The Launchpad bug tracker is the glue between the official projects and the backports. If you have contributed or tested a bugfixing branch to on of the official projects, you can can prepare a merge proposal on the corresponding backports project. Due to limitations of Launchpad it is not possible to create a proposal for the same branch on different projects. Therefore, the procedure would be to start all over with a branch of the backports project, make your changes, push and propose. You can do that manually but we wanted to provide a tool to streamline this a little bit. We came up with a clone script for merge proposals [3], which allows you to propagate (unmerged) bugfixing branches and their proposals to the backports branches. You can read up on how to use it here [4]. This is also a recent development, so use with care.
> 
> If you have a bugfix that you can vouch for, please add the appropriate backports branch to the OpenERP bug in Launchpad, by clicking 'Also affects project'. Also indicate the version that is affected by clicking 'Assign to series'. Set the bug status on this series to 'fix committed'. Please do not touch any setting from the official project, as this is the domain of the OpenERP developers.
> 
> Please indicate on the proposal if you run the modification in production, or if the same bugfix has been approved or merged by the OpenERP developers.
> 
> No new bugs should be filed on the backports projects proper unless they report a regression specific to the backports. Similarly, no code should be submitted to the backports projects that is not submitted to, or present in the official branches.
> 
> You may encounter an OPW branch that you want to have merged without a bug report. There usually is one or even more bug reports on the same issue. In that case, you can link the bug report to the branch and continue from there. Otherwise file the bug yourself.
> 
> * New features
> 
> We would suggest that new features should not qualify as candidates for the backports branches, but maybe a separate series could be started for those living on the edge. Also, heavy refactorings should not be adopted lightly, because they might put stability at risk or because they cause conflicts in the mirroring system more easily.
> """
> 
> Hope this helps,
> 
> 
> Regards,
> 
> Joël
> 
> 
> Le 5 avr. 2013 à 10:44, Carlos Liébana <carlosliebana@xxxxxxxxx> a écrit :
> 
>> Hello Mario,
>> 
>> Besides all the Nhomar speech, that I do respect, we and some other companies have decided to stay in 6.1. I don't want to open again the Pandoras box, because I also respect OpenERP SA a lot since they make my way of living and I don't like the way sometimes we can critize them: they are a company trying to make it as we are, and they have their rules, roadmap, partners offerings and business plans. If you like/agree with them I think it's great, but if you don't it's also great because we have the freedom to choose what to do.
>> 
>> So going back to the point: we see ourselves in the 6.1 for some time. We (representing some Spanish companies, not just my company) have been lately starting to make a deep analysis of existing bugs and pending merges to start the community branch from the original one. But we've studied existing non-official branches (Therp, c2c, Akretion, ours...) and came to the conclusion that Therp's one is the best. I think that should be the starting point, of course if everybody agrees or prove that we are wrong.
>> 
>> But, we've problems coming soon, because maintaining branches is a hard work not suitable for non-expert people. I see two different projects here:
>> 1) Making the best 6.1 branch in the world, including:
>> 1.1 - Not solved bugs but with pending merges.
>> 1.2 - Not solved bugs without pending merges.
>> 1.3 - Some features that could break compatibility with the original one, but improving OpenERP.
>> 
>> 2) Maintaining that branch, including:
>> 2.1 - Taking care of bug reporting
>> 2.2 - Testing and accepting merges
>> 
>> The second point is the one that freaks me out, because maybe the suitable thing would be... get some funds and have some people (from Therp?) in charge of it.
>> 
>> Anyway this is a hard decision to make but I'm with Mario that we should do something soon.
>> 
>> 
>> 
>> 2013/4/5 Nhomar Hernández <nhomar@xxxxxxxxx>
>> Hello Mario.
>> 
>> I think policy is correctly explained here:
>> 
>> http://doc.openerp.com/v6.1/contribute/11_bug_tracker.html
>> 
>> And the rule is simple.
>> 
>> Openerp 6.1 is deprecated since 1 year ago, when Version 7.0 starts to be planified.
>> 
>> To avoid get fixed things only in trunk, you should buy an Openerp Enterprise and OpenERP itself can make the push to 6.1.
>> 
>> https://www.openerp.com/en/pricing
>> 
>> If This is not an option for you, you can make by your own, and mantain your branch.
>> 
>> I am an stronger believer of Community, but in my experience, try to mantain just your branch bring to you more work than solutions (I life this since 4 years ago and + 30 customers)
>> 
>> Even mantain just a set of modules is difficult "Imagine maintain all the core."
>> 
>> Some comments in line.
>> 
>> 
>> 2013/4/4 Mario Arias <the.clone.master@xxxxxxxxx>
>> Hi,
>> 
>> It is time that we, as a community, start defining how we will keep 6.1 alive and moving forward.  After all, it is the most recent "real life proven"  version available right now, as V7+ is only good for "SorrySAP Fantasy Land" and taking your lunch orders...
>> 
>> Don't get me wrong, I like many improvements on v7, but it will take one or two years to be able to use it for real ERP environments (it IS an ERP after all, isn't it ?? )
>> 
>> I really think we have more improvements than failures, (but we have a lot of failure i know)
>> 
>> 
>> 
>> So....  how should we proceed to keep 6.1 working in the mean time ??
>> 
>> It is working now, and if you want to receive push on it, you should buy an OPW, i think it is a good point to do it, because it was extended until +1 year I think, and you __since now__ can prepare and migrate and test everything with a year of planification to move to 7.- or 8.0 may be in ... one year?.
>>  
>> 
>> OpenERP S.A. already "deprecated"  6.1 series on LP (now they are back but it is not clear for how long...)
>> 
>> 
>> The date is known dude, it was mentioned at last november and extended past february, if openerp 7.0 is not good enought yet (I think we have together a lot of work here) IMHO is better mantain the new one than by fear stay  in the past.
>> 
>>  
>> Many bug fixes are being only applied to 7.0+
>> 
>> Even with OPW, it seems bug fixes are not being aplied on 6.1, as you can read on 
>> https://code.launchpad.net/~openerp-dev/openobject-addons/6.1-opw-581633-rgo/+merge/134877
>> 
>> I think we have here a misunderstood, if this fix works for you (let me tell you i dont need it) you can run an 
>> 
>> bzr merge branch 
>> 
>> In your local enviromet test and use it.... if you use just blessed packages you have a different problem, but I think you just need to buy an OPW and ask too! for this merge, I am pretty sure they will make
>> 
>> I have several examples where the merge is done and other that doesn't for several reasons, you must fight the point and this is all, This is a community I think.... 
>> 
>> 
>> Even you can test it automatically here:
>> 
>> http://runbot.openerp.com/
>> 
>> ctrl + f (nick of branch)
>> 
>> And ask to build in 10 minutes you will have a test enviroment.
>> 
>> 
>> 
>> When (not if) the 6.1 series are finally removed by S.A., how could we continue to report bugs and fixes ?
>> 
>> 
>> Easily, you continue report in Launchpad, and maintain by yourself, or some members of community or... move to 7.0, Again you have one year my friend. 
>> 
>> Last time I checked OCB community branches are only created for 7.0, and besides the policy is that bugs should be opened on "official branches" before being considered for inclusion on the community ones...
>> 
>> 
>> Dude you have a misunderstood here....
>> 
>> This is the policy:
>> http://doc.openerp.com/v6.1/contribute/11_bug_tracker.html
>> 
>> And this are the community managed teams.
>> http://doc.openerp.com/v6.1/contribute/05_developing_modules.html#community-addons
>> 
>> I dont understand why do you think if OpenERP SA decide by themselve manage some bug policy, you think you can not report them... you can, but is not responsability of nobody mantain something already obsolete..... at least that you want to do it (and i think it is a bad decisition) You should move to version 7.0 as soon as possible. 
>> 
>> I am tired and frustrated of reporting bugs on LP, and see them at most fixed for trunk...
>> 
>> This is the policy:
>> 
>> Simple.
>> 
>> For free in trunk.
>> Payed in Stable.
>> More payed (where you want).
>> For free of everything (just cost in your time) make the merge by yourself 
>> 
>> 
>> Please, share your thoughts !!!
>> 
>> 
>> Regards,
>> -Mario
>> 
>> I am a little worried about some OpenERP develompent decisions, but now I think even imagine stay in 6.1 is a really madness....
>> 
>> We as community must improve and continue testing deeper and deeper in our envirometn version 70
>> 
>> I REALLY think the useability stuff and the finish of JS framework is an amazing job.
>> 
>> We trained at least 50 people already in V7 and +300 in 6.x versions and I must to say that i was amazed with with the 50% of information in our trainings on V70 people could excecute 100% of tasks with 30 % or even 40 % of less job on our side....
>> 
>> What I say, and I hope my bad english allow me is that the the solution is MORE AND MORE test on V7.0
>> 
>> Defend the points.
>> 
>> Test in your enviroments, 
>> 
>> Dont try to stop the evolution...
>> 
>> Because in a way or another, I think it is taking the correct Way....
>> 
>> @openerp and @fpopenerp
>> 
>> Please dont fail us, stop take features and not hear the Community, we are facing a lot of problems as Mario Says, and I think Mario is facing a lot of things that other community members are facing
>> 
>> @mario
>> 
>> Men, support OpenERP is NOT use OpenERP is help us to move forward with ALL the support and playing this game together, not pushing in a way that __just__ help a little quantity of people.
>> 
>> The Enterprise licence in My opinion is Mandatory for serious enviroments, if you dont Suppor OpenERP, How can you demmand them support?
>> 
>> 
>>  
>> 
>> _______________________________________________
>> 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
>> 
>> 
>> Best Regards My 2 cents.
>> 
>> -- 
>> --------------------
>> 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
>> 
>> _______________________________________________
>> 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
>> 
>> 
>> _______________________________________________
>> 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
> 
> 
> 
> --
> 
> Camptocamp
> Innovative Solutions by Open Source Experts
> 
> Joël Grand-Guillaume
> Division Manager - Business Solutions
> 
> www.camptocamp.com
> 
> 

-- 

camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager
Business Solutions

+41 21 619 10 28

www.camptocamp.com