openerp-community team mailing list archive
Mailing list archive
Proposal for a community backports project
In response to a discussion on this list that ended around here , 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
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.
The project urls are:
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
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 . 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
, 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 . 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
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.
Therp - Maatwerk in open ontwikkeling
Stefan Rijnhart - Ontwerp en implementatie
tel: +31 (0) 614478606