← Back to team overview

openerp-community team mailing list archive

Re: Proposal for a community backports project

 

Dear all community members,


Well after having a talk internally and as we already maintain our own branch, we decide to jump in that project. We are in favor of building a community back port project, owned by all  community reviewer team ! We'll gonna move our own fixes in it and contribute to that branch.

I invite all other contributors to join us. 

@Stefan : I let you change the ownership of the branches in your project. Thanks you for this initiative !


Regards,


Joël



Le 8 févr. 2013 à 15:25, Stefan Rijnhart <stefan@xxxxxxxx> a écrit :

> Hi,
> 
> In response to a discussion on this list that ended around here [1], we at Therp want to propose a new community project for maintaining a set of branches of OpenERP with a number of additional bugfixes. Below are our suggestions as to how such a project should be organized. We are curious to know what you think and how we can run this project together.
> 
> This is not a fork. We love OpenERP and how OpenERP SA is developing and marketing it. They even acknowledged that bug fixes were not merged fast enough in the 6.1 lifecycle. But even a dramatic improvement in this respect will not satisfy everyone. Like many other parties supporting OpenERP, we need branches that include at least the bugfixes that we delivered to our customers. We know that many parties maintain such branches. Therp has maintained theirs publically and used the Launchpad bugtracker to track which bugs it includes. As has been said a couple of times about this theme, 'we may as well share the effort'.
> 
> This is not for the faint of heart. As Olivier Dony reminded us recently on twitter, the current bug fixing policy is partly the result of the 5.0 days in which bugs were fixed and merged on stable very quickly, which lead to a lot of regressions. Also, this is not a project in which end users can participate or will be supported. This is a project for developers who review each others bugfixes. Sorry if you are a user who expected more in this respect. Then again, anyone can hire a developer to participate.
> 
> Please bear in mind that although the text below is written as a set of guidelines, it is just a proposal that is open to discussion.
> 
> * Projects
> 
> The project urls are:
> - https://launchpad.net/ocb-addons
> - https://launchpad.net/ocb-server
> - https://launchpad.net/ocb-web
> 
> These projects have 7.0 series only for now. If other contributors are interested in series for older versions of OpenERP, these can be added as well.
> 
> * 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.
> 
> * Team membership
> 
> The ocb team which commits the approved fixes is open for regular contributors. We would be pleased to have the community reviewers team as a member of this project, but that decision should be left to the good people of CampToCamp, who are the most active participants of this team by far. Of course, not being a member of ocb does not restrict anyone in submitting or reviewing merge proposals.
> 
> We would like to invite you to respond with your insights concerning the suggested workflow and guidelines as suggested above.
> 
> Cheers,
> Stefan
> 
> 
> 
> [1] https://lists.launchpad.net/openerp-community/msg01492.html
> [2] http://bazaar.launchpad.net/~therp-nl/lp-community-utils/replaybot_clone_mp_to_community/view/head:/replay_missing.py
> [3] http://bazaar.launchpad.net/~therp-nl/lp-community-utils/replaybot_clone_mp_to_community/view/head:/clone_mp_to_community.py
> [4] https://answers.launchpad.net/ocb-addons/+faq/2222
> 
> -- 
> Therp - Maatwerk in open ontwikkeling
> 
> Stefan Rijnhart - Ontwerp en implementatie
> 
> mail: stefan@xxxxxxxx
> tel: +31 (0) 614478606
> http://therp.nl
> https://twitter.com/therp_stefan
> 
> 
> _______________________________________________
> 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

+41 21 619 10 28

www.camptocamp.com




References