openerp-community team mailing list archive

[Stefan Rijnhart <stefan@xxxxxxxx>]

On 04/05/2013 10:44 AM, Carlos Liébana wrote:
> 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.

Hi,

speaking on behalf of Therp, if our current branches would be used as a 
starting point they should be moved to the Community Backports projects. 
We could then actively participate in the maintenance of these branches 
in the community backports projects, helping to review other people's 
proposals. Any new proposals from our side would from then on also have 
to be approved by another party.

Using another party's modified branches is a pretty serious matter of 
trust. I would therefore like to invite everyone who is considering this 
option to investigate the changes that we made compared to the official 
branches. Please have a look here:

https://code.launchpad.net/therp-backports?field.lifecycle=MERGED

It may be an issue that a small number of changes add a field and 
require a module upgrade. Then again, you would need to upgrade anyway 
to take advantage of some of the fixes in views.

At least two of these changes can be identified:

http://bazaar.launchpad.net/~therp-nl/therp-backports/openerp-addons-6.1/revision/6693
http://bazaar.launchpad.net/~therp-nl/therp-backports/openerp-addons-6.1/revision/6705

These changes do not strictly adhere to the defacto policy of the 
community backports projects. However, other proposals that change the 
database layout may keep coming up. One option could be to revert the 
changes for the 'stable' branch and set up another series for 'unstable' 
changes such as the ones above.

As for sharing the workload, I think we should aim for voluntary 
technical involvement from as many parties as possible, and stay away 
from funding a small amount of participants. Part of the deal should be 
for people who suggest any changes to help reviewing other proposals.

Cheers,
Stefan.


--
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