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 <ste...@therp.nl> 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: ste...@therp.nl
> tel: +31 (0) 614478606
> http://therp.nl
> https://twitter.com/therp_stefan
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@lists.launchpad.net
> 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



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : openerp-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp

Reply via email to