Hi,
It is time that we, as a community, start defining how we will keep 6.1
alive and moving forward. After all, it is the most recent "real life
proven" version available right now, as V7+ is only good for "SorrySAP
Fantasy Land" and taking your lunch orders...
Don't get me wrong, I like many
Hello Mario.
I think policy is correctly explained here:
http://doc.openerp.com/v6.1/contribute/11_bug_tracker.html
And the rule is simple.
Openerp 6.1 is deprecated since 1 year ago, when Version 7.0 starts to be
planified.
To avoid get fixed things only in trunk, you should buy an Openerp
En
Hello Mario.
I think policy is correctly explained here:
http://doc.openerp.com/v6.1/contribute/11_bug_tracker.html
And the rule is simple.
Openerp 6.1 is deprecated since 1 year ago, when Version 7.0 starts to be
planified.
To avoid get fixed things only in trunk, you should buy an Openerp
En
Hello Mario,
Besides all the Nhomar speech, that I do respect, we and some other
companies have decided to stay in 6.1. I don't want to open again the
Pandoras box, because I also respect OpenERP SA a lot since they make my
way of living and I don't like the way sometimes we can critize them: they
Dear community members,
I want to point out that we now have an "official" community branch for 6.1
maintained by the community reviewer team
(https://launchpad.net/~openerp-community-reviewer).
The project urls are:
- https://launchpad.net/ocb-addons
- https://launchpad.net/ocb-server
- https
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 merge
Hello Joël,
Please correct me if I'm wrong, but no 6.1 series there, just 7.
2013/4/5 Joël Grand-Guillaume
> Dear community members,
>
>
> I want to point out that we now have an "official" community branch for
> 6.1 maintained by the community reviewer team (
> https://launchpad.net/~openerp-
My mistake... You're right, sorry for that.
Le 5 avr. 2013 à 11:34, Carlos Liébana a écrit :
> Hello Joël,
>
> Please correct me if I'm wrong, but no 6.1 series there, just 7.
>
>
> 2013/4/5 Joël Grand-Guillaume
> Dear community members,
>
>
> I want to point out that we now have an "offi
Hello folks,
just a few remarks:
at Akretion, in theory we totally support the Therp initiative and will try
to join efforts here as much as possible (yes we know we don't do enough
here yet sorry).
At some points we did many sacrifices to support OpenERP SA vision. Overall
we loose lot of effort
Hello guys,
Savoir-faire Linux will be very happy to join the effort once:
* openerp-community-reviewer team is part of the ocb team.
* 6.1 series are created with their respective branches
Thanks.
--
Maxime Chambreuil
1-514-276-5468 #126
- Mail original -
Dear communi
Thanks Nhomar and Carlos, that's the discussion we need!!
Nhomar, you illustrated perfectly my point...
OpenERP S.A. has a policy about but fixing, but it is BROKEN !
- How many bugs are reported without an OPW?
- Does it mean they are not important bugs?
- Where will they be fixed? I
On 04/05/2013 06:59 PM, Maxime Chambreuil wrote:
Savoir-faire Linux will be very happy to join the effort once:
* openerp-community-reviewer team is part of the ocb team.
Hi Maxime,
that is done.
* 6.1 series are created with their respective branches
We can create the series and b
If everyone agrees to use your branch as the 6.1 series, we will follow.
Otherwise, we agree with your suggestions : use 6.1 branch from
openobject-addons and resubmit the backports through the community review.
--
Maxime Chambreuil
1-514-276-5468 #126
- Mail original -
On 04/05/
+1
On Fri, Apr 5, 2013 at 10:29 PM, Maxime Chambreuil <
maxime.chambre...@savoirfairelinux.com> wrote:
> Hello guys,
>
> Savoir-faire Linux will be very happy to join the effort once:
>
>- openerp-community-reviewer team is part of the ocb team.
>- 6.1 series are created with their respe
+1 to use yours Stefan.
Le 5 avr. 2013 à 23:10, Maxime Chambreuil
a écrit :
> If everyone agrees to use your branch as the 6.1 series, we will follow.
>
> Otherwise, we agree with your suggestions : use 6.1 branch from
> openobject-addons and resubmit the backports through the community revie
On 04/08/2013 01:08 PM, Joël Grand-Guillaume wrote:
+1 to use yours Stefan.
Well thank you for your trust in that matter.
Can we have the vote on using a single series or branch that may contain
changes to the database layout, or using separate 'stable' and
'unstable' branches?
Cheers,
Ste
Avanzosc also agrees on using yours, stefan...
2013/4/8 Stefan Rijnhart
> On 04/08/2013 01:08 PM, Joël Grand-Guillaume wrote:
>
> +1 to use yours Stefan.
>
>
> Well thank you for your trust in that matter.
>
> Can we have the vote on using a single series or branch that may contain
> changes t
+1 for 2 separate branches
Alexandre
On 08/04/2013 13:18, Stefan Rijnhart wrote:
> On 04/08/2013 01:08 PM, Joël Grand-Guillaume wrote:
>> +1 to use yours Stefan.
>
> Well thank you for your trust in that matter.
>
> Can we have the vote on using a single series or branch that may
> contain change
I vote in favor of having 2 series in that case, so one will never change the
DB structure.
Le 8 avr. 2013 à 13:18, Stefan Rijnhart a écrit :
> On 04/08/2013 01:08 PM, Joël Grand-Guillaume wrote:
>> +1 to use yours Stefan.
>
> Well thank you for your trust in that matter.
>
> Can we have the
Well I vote for 1 branch for 6.1 serie. The server provides the mecanism for
module upgrade and we should use it.
By using it, module upgrades and migrations would not be such a big step and
would reduce the risk and effort.
If we start today with 2 branches on the 6.1 serie, we will have m
Vote for 1 branch. Don't care about minor change in the DB structure as
long as it is not contact_id in partner_id magnitude.
Regards
Goran Kliska
*Slobodni programi d.o.o.*
*Gorjanska 23, Zagreb, Croatia*
*
*
> Well I vote for 1 branch for 6.1 serie. The server provides the mecanism
> for module
+1 to one branch.
Too much of the "no changes to data model" already on official
branches. After all, moving to OCB branch is almost sure a "one way
trip"...
Regards,
-Mario
On 04/08/2013 06:48 AM, Goran Kliska wrote:
Vote for 1 branch. Don't care about minor change in the DB structure
as
On 08-04-13 16:30, Mario Arias wrote:
+1 to one branch.
Too much of the "no changes to data model" already on official
branches. After all, moving to OCB branch is almost sure a "one way
trip"...
I'm sure your second remark can be interpreted in multiple ways, but I
just wanted to emphas
Hello,
My main concern is that for the 7.0 OCB branch, we try to only merge
changes which have a chance of getting merged in the official branch.
This means "no db layout changes" in there. Ideally I would like to
make sure that the fixes which are pushed in the 6.1 branch are also
made availa
On 04/08/2013 05:09 PM, Alexandre Fayolle wrote:
If we are to accept changes which affect db layout, we need a clear
policy about what changes are acceptable, and how to label them. At the
very least, updating the version number of the addon should be
required, a tag in the commit message and a m
25 matches
Mail list logo
