c2c-oerpscenario team mailing list archive

["Fabien \(Open ERP\)" <fp@xxxxxxxxxxx>]

Hello,

Here is what we plan to improve:
- the main trouble with OpenERP v5 was that we did too much changes on
  the stable branch which introduced regressions. (because our support
  team was fixing a maximum of requests on stable branch reported by the
  community. -> very risky.
- Only a very few of these changes where impacting our customers,
  changing a stable branch used by customers in production is always a
  risk we should try to minimize.
- Most of these requests (evaluated to 65% according to our
  latest qualification sprints) where feature improvements, not bugs.
- The distinction was not clean between bugs fixed through the
  maintenance contract and those fixed for free on launchpad. We tried
  our best to fix both.

We consider that:
- Fixing something on a stable branch is a service to a (few) customers
- Improving the future version will help the mass, so it's good for the
  community.

We should focus all our free services on things that will help the mass
of user (= improve the trunk). So, our launchpad team mainly works on
the trunk.

We should change the stable only if it impacts a real customer in
production in order to avoid regressions and minimize the changes made
on the stable. We must also improve the process of merging something in
a stable branch:
  - code review
  - announce to customers
  - release of a new version if required

In order to improve this, we splitted our R&D into two teams:
   1. R&D future versions (trunk)
   2. Maintenance of stable versions.
We know have clear priorities and different process on both teams. (fix
on a stable branch through a maintenance must be processed within a few
days, bugs on trunk must be qualified quickly and fixed according to
priorities defined on sprint roadmaps.)

This also allows us to better manage our budget and team size: customer
service of the OpenERP Publisher Warranty is a priority for us, we
recruit people according to the number of customers. The R&D is
important too, but must focus on creating value for OpenERP, future
versions.

The team that works on launchpad works only on the trunk branch. They
can not commit to the stable branch in order to keep a strong code
review and quality process on the stable. They will fix every bug
proposed by the community. In order to guarantee this, we setup a bug
qualification team that does a quick and first review of every bug
proposition.

If, and only if, a customer of the OpenERP Publisher Warranty contract
reports a trouble on a stable branch, the maintenance team will fix all
stable branch on which we have customers with maintenance impacted by
the trouble: 4.2, 5.0, 6.0, 6.1, etc.


The advantages of doing this clear distinction:
- stable branches are safer to use in production, risks of regressions
  are decreased because only 2 people have write access and we do the
  minimum required to satisfy all customers.
- the R&D team can focus on improving OpenERP, not on maintaining all
  preceeding versions. -> easier for planification of sprints.
  This is specially important since we plan to release a new stable
  version every 6 months -> R&D must be focused on new developments, the
  process of maintaing

As a summary:
- if a community member report something on launchapd, we fix in trunk
- if a customer report something we fix (or backport a trunk fix) in all
  stable branches.

So the responsibles of each branch are clear and we can setup continuous
improvement process for trunk and stable branches that have different goals.

If somehting is broken in a stable branch, we clearly have a responsible
because only a very few people will have access to stable. this is good
for the continuous improvement process.

We tag as "won't fix" because we need to manage the list of open bugs.
Our goal is to have an empty list of bugs and we dedicated a bug
qualification team for this. If we keep everything open, it's impossible
for us to manage what still have to be done for our teams and planify
sprints, review priorities, etc.

It's better to keep an up-to-date list of bugs which is processed
quickly than keeping every bug open for months/years, even if we will
not work on them. That's the role of the bug qualification team, and
they need to clean their list o bugs they maintain.

If someone plans to contribute, I propose you to reopen and assign to
yourself or another project.

Nicoleta, can you explain and write a faq for this ? ODO improved the
community guide, you can see with him for more info.

Alexis de Lattre wrote:
> OK, you are free to say that OpenERP S.A. doesn't want to fix this bug
> because it only affects the official OpenERP stable version. I don't
> oblige anybody to fix it. But why do you put the status to "won't fix" ?
> I let users think that nobody will fix the bug... which gives a bad
> image of the OpenERP community.
> 
> Maybe I will take the time to fix the bug myself, if I have some spare
> time. Maybe someone else in the community will find this bug and fix it.
> So the "won't fix" status is inappropriate. I think we should leave the
> Status as "new" or create an "OpenERP S.A. won't fix" flag.
> 


-- 
Fabien Pinckaers
CEO OpenERP
Chaussée de Namur 40
B-1367 Grand-Rosière
Belgium
Phone: +32.81.81.37.00
Fax: +32.81.73.35.01
Web: http://openerp.com

-- 
Can't save a new predefined export
https://bugs.launchpad.net/bugs/671512
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.

Status in OpenObject GTK Client: Won't Fix

Bug description:
With OpenERP Client 5.0.15 and OpenERP Server 5.0.15, here is the bug scenario :

0) Open an object (let's say the "Partners" for example)
1) In the menu : Form > Export Data
2) I select a field and clic on "Add"
3) I open the prefefined Exports
4) I click on the "save list" button
5) In the pop-up, I give a name to the export and clic on "OK"

=> Problem : The export is not saved.

Note : I opened the bug against OpenObject Client, but it may be a bug elsewhere, I don't know...