openerp-community team mailing list archive
-
openerp-community team
-
Mailing list archive
-
Message #02209
Re: Proposal for a community backports project
Dear all contributors,
First of all I want to thanks Stefan for his suggestion here (as well as for his investments in the community reviewer team). We do have at Camptocamp such a set of branches including fixes that we need for our customers (they are also public, but currently with no link on bug report [1] ).
Having such a branch shared for all the community sounds good to me as we all need some fixes from OpenERP SA to be merged and still waiting month till they land in the official branch... This is the reasons why we created our own version. Unlike what is suggested here, we do not merge OpenERP's branch every day, this is mainly to avoid regressions. The fact is, we mostly merge official branch when a bug discovered by our customer is found and already fixed in the official one.
Apart from those details, we built those branches for the same reasons: having bugfixes that matters for us fixed in a blink to please our customers. Sharing this between all the community seem to make sense and have already been discussed between us, Akretion, Syleam and some others. As you said, this is not a fork, but a community maintained branch that serve our needs in term of merging bugfixes.
Camptocamp join the point of view and rules that you suggest here Stefan and really appreciated that you're pushing on that topic. My concern is now a matter of resources.
1) Having a look on the community-reviewer team [2], I see that many of the members do not invest a lot of time in the community reviews. I do not mean to be rude, but this is the truth. Most of the work/review is currently made by Camptocamp, Stefan, Maxime and sometimes a few others. Some of the members do not even made a single comments on any MP.
2) Reviewing the MP on the core will take even more time than reviewing the community projects. We'll need to test every proposal and we'll not be able to "just" have a look on the code.
Once again, I just want to reflect the fact, I do not mean to criticize. Everybody invest the time he can, at a point we (meaning here the community-reviewer team) may decide to vote for removing people that simply cannot invest time, but this is another story.
Then, starting from those fact, the Camptocamp point of view is that we are in favor of making such a community branch, but we will not be able to provide the needed resources to review this work. We already making everything we can to assume the review on the current community projects. At the end, it's a community decision. Camptocamp is in favor of putting those branches there, but won't be able to assume all the work.
So, what are your opinion ? Who can invest time to help review those new branches ?
Regards,
Joël for the Camptocamp's team
[1] Our OpenERP branches (for 7.0):
lp:~camptocamp/openobject-addons/7.0-c2c-official
lp:~camptocamp/openobject-server/7.0-c2c-official
lp:~camptocamp/openobject-client-web/7.0-c2c-official
[2] https://launchpad.net/~openerp-community-reviewer/+members :
Borja López Soilán (NeoPolus)
Camptocamp Community Reviewer
Eric Caudal - www.elico-corp.com
Jordi Esteve (www.zikzakmedia.com)
Joël Grand-Guillaume @ camptocamp
Maxime Chambreuil (http://www.savoirfairelinux.com)
Nhomar - Vauxoo
Niels Huylebroeck
Olivier Dony (OpenERP)
Omar (Pexego)
Raphaël Valyi - http://www.akretion.com
Serpent Consulting Services
Stefan Rijnhart (Therp)
Vauxoo Community Reviewer
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
Follow ups
References