Hello,
The community doesn't spend a lot of time currently on bug planning because
we still can't do it efficiently unless you do what I list here:
** problems for 5.0.x bug planning **
We can't plan bugs on 5.0.x releases because we don't know any release
calendar. 5.0.7 was announced a
A Dimecres, 20 de gener de 2010, Raphaël Valyi va escriure:
> Hello,
>
> The community doesn't spend a lot of time currently on bug planning because
> we still can't do it efficiently unless you do what I list here:
snip
> I talked about that with Fabien, Quentin and Christophe and we all agree
Hello Albert,
The current situation is that most integrators that have a critic mass have
there own branch of OpenERP with their own fixes instead of the Tiny branch:
example include:
- Syleam
- CampToCamp
- Almacom
- Hellug
- Chricar?
- Axelor/Tiny themselves with branches like
https://code.launc
A Dijous, 21 de gener de 2010, Raphaël Valyi va escriure:
> Thoughts?
I think if we created a stable community branch we could:
- Get the same fixes tiny is currently doing (those 10 commits a day).
- Because of the "two-step" commits we would revise, discuss and maybe detect
some of the regressi
Albert,
if we do so, say in Mars 2010 and we have a good parallel 5.2 and Tiny their
own 5.2 too. If there is a big delta on fundamental things like how to
handle rounding, how modules are split together (not sure the tax_include
modules are worth as externals, not sure, mrp should depend on hr ju
A Dijous, 21 de gener de 2010, Raphaël Valyi va escriure:
> Albert,
>
> if we do so, say in Mars 2010 and we have a good parallel 5.2 and Tiny
> their own 5.2 too. If there is a big delta on fundamental things like how
> to handle rounding, how modules are split together (not sure the
> tax_inc
Am Donnerstag 21 Januar 2010 01:37:35 schrieb Albert Cervera i Areny:
> A Dijous, 21 de gener de 2010, Raphaël Valyi va escriure:
> > Albert,
I think we have to consider
* OpenERP (as any other) must comply to legal and audit requirements (top
priority)
* OpenERP partners contribute (code, fee) an
On Wednesday 20 January 2010, Albert Cervera i Areny wrote:
> Maybe it would be better for tiny and the community to have one
> openerp-server and openerp-addons branches owned by community-leaders or
> another restricted group that would do their own priorization and
> schedules? I'm not sure,
About migrating to 5.2, after some tests yesterday, I noticed that 5.2
isn't ready at all.
Some menus are missing. Due to the new filter method, and new approach
(wich is the good one for me too) to have less menu.
I agree with Raphael with the fact that 2 branches are going to have a
big delta.
I do mostly agree with P. Christeas,
It would be outrageous to have a official stable release and a community
maintained "super-stable" release.
Here also we would run into troubles when Tiny doesn't accept (a part
of) our super-stable release merged into the official stable release.
From marke
Op 21-01-10 10:26, Zyphos schreef:
So, if Tiny has its own branch for his customers use, why Community
members can't join the OpenERP Quality Team ?
Most of current members of this team have a very low karma.
I think that OpenERP Quality Team should be indeed restricted to very
few people but
A Dijous, 21 de gener de 2010, Jan Verlaan - Veritos va escriure:
> I do mostly agree with P. Christeas,
>
> It would be outrageous to have a official stable release and a community
> maintained "super-stable" release.
> Here also we would run into troubles when Tiny doesn't accept (a part
> of) o
Hi !
For the good of all, Tiny must keep the lead on the main branch, saving time
for everyone.
Having our own branch here @ Camptocamp cost us time and money. Could be much
better for everyone if we could avoid that !
My point is, with simple little details, we can achieve that !
I think the
This whole discussion seems to revolve around power, who has it, who
wants it and which is better for the project on the long and short term.
To simplify the discussion I will refer to the *trunk* if we're talking
about long term and *stable* if we are talking about short term goals.
Who has pow
Hi All,
As Joel said "Tiny must keep the lead on the main branch, saving time for
everyone."
Its necessary to find a good workflow to implement this.
For example:
The bug of 'Exceptions not being classes' in py2.6 was fixed in orm and osv
by me about 6 weeks back and proposed for a merge. Yeste
On Friday 22 January 2010, Niels Huylebroeck wrote:
> This whole discussion seems to revolve around power, who has it, who
> wants it and which is better for the project on the long and short term.
>...
I think this whole discussion is driven by the limitations of the current VCS,
which turns out
Hi,
> I think this whole discussion is driven by the limitations of the current
> VCS,
> which turns out to be centralized in an unproductive way.
>
I think the Bazaar VCS is may be not perfect, but certainly not the source of
trouble...
Even if some feature are missing in this one, We have a
P. Christeas wrote:
Trying to control access to a limited set of branches, and then endlessly
discussing about what each branch should contain, is the same plague that
Subversion had introduced in OSS projects.
That plague is not technical nor VCS bound, it's just the fact that Tiny
wants an
> To conclude:
> Opensource works because it should have a fast turnaround, release early,
> release often, repeat that mantra and realize it's full potential.
+1 :) !
--
Joël Grand-Guillaume
OpenERP Consultant
Business Solutions
Camptocamp SA
PSE A, CH-1015 Lausanne
www.camptocamp.com
A Divendres, 22 de gener de 2010, Joël Grand-Guillaume va escriure:
> For the good of all, Tiny must keep the lead on the main branch, saving
> time for everyone. Having our own branch here @ Camptocamp cost us time
> and money. Could be much better for everyone if we could avoid that !
snip
>
A Dijous, 21 de gener de 2010, P. Christeas va escriure:
> On Thursday 21 January 2010, Albert Cervera i Areny wrote:
> > I just wanted to say that I share your worries. At the same time we don't
> > want a "community branch" because it could become a "community fork",
> > but currently there are
Albert Cervera i Areny wrote:
It's not a discussion on *how* something should be solved. It's simply that Tiny does not
have enough resources to fix things we all agree on how should be fixed.
My personal experience with Tiny is more of the sense that even if you
fix it yourself (and after
A Divendres, 22 de gener de 2010, Niels Huylebroeck va escriure:
> Albert Cervera i Areny wrote:
> > It's not a discussion on *how* something should be solved. It's simply
> > that Tiny does not have enough resources to fix things we all agree on
> > how should be fixed.
>
> My personal experience
On Friday 22 January 2010, you wrote:
> Although I personally also prefer git over bazaar I think we need to take
> into account several things:
It currently is only the practical side (I don't claim it to be the ultimate
solution), but I may have some answer to your concerns:
> - Though a good
Has someone asked Tiny already to let the community commit their fixes
into the so called "stable" which is actually un-stable?
Just to legitimate that we have no other choice then to branch to a new
community bugfix-release.
I'm a little bit worried about the consequences it could have, like th
Jan Verlaan - Veritos wrote:
Has someone asked Tiny already to let the community commit their fixes
into the so called "stable" which is actually un-stable?
Just to legitimate that we have no other choice then to branch to a
new community bugfix-release.
I'm a little bit worried about the conse
I totally agree with your exposition, Niels :-). But wouldn't it be nice
IF community AND Tiny could work in same branch?
That would be a win-win situation. Both parties don't have to backport
to each version.
From that point of view I asked my previous question: " Has someone
asked Tiny alrea
Jan Verlaan - Veritos wrote:
I totally agree with your exposition, Niels :-). But wouldn't it be
nice IF community AND Tiny could work in same branch?
That would be a win-win situation. Both parties don't have to backport
to each version.
>From that point of view I asked my previous question:
In respect of getting patches in - it's probably a question of "karma" - (not
necessary the one in Launchpad.)
Very often my "little", often trivial patches get now integrated very soon
(some days) thanks to Jay.
So TIny makes a big effort compared to some time ago.
for some more complex patc
-community-leaders] Simple things we need from Tiny for
better bug planning/management
In respect of getting patches in - it's probably a question of "karma" - (not
necessary the one in Launchpad.)
Very often my "little", often trivial patches get now integrated very soon
On Fri, Jan 22, 2010 at 3:27 PM, Ferdinand Gassauer wrote:
> In respect of getting patches in - it's probably a question of "karma" -
> (not necessary the one in Launchpad.)
>
> Very often my "little", often trivial patches get now integrated very soon
> (some days) thanks to Jay.
>
BTW, I hope
2010/1/22 Raphaël Valyi
> 5) Finally, yes, helping CampToCamp to build a decent testuite with
> OERPScenario https://launchpad.net/oerpsenario is a large part of the
> solution.
>
> Yes, I believe good testing is critical, but how professional does it look
when there is a typo in the project name
On Fri, Jan 22, 2010 at 10:28 PM, Niels Huylebroeck wrote:
>
>
> 2010/1/22 Raphaël Valyi
>
> 5) Finally, yes, helping CampToCamp to build a decent testuite with
>> OERPScenario https://launchpad.net/oerpsenario is a large part of the
>> solution.
>>
>> Yes, I believe good testing is critical, but
A Divendres, 22 de gener de 2010, Raphaël Valyi va escriure:
> 2) I see that some of you more or less support the idea of the branch X I
> defined: a stable branch synch'ed with 5.0 head with extra backports Tiny
> doesn't want / can't assume. If only backports can get in, then that's
> pretty easy
On Sat, Jan 23, 2010 at 3:21 PM, Albert Cervera i Areny
wrote:
> A Divendres, 22 de gener de 2010, Raphaël Valyi va escriure:
> > 2) I see that some of you more or less support the idea of the branch X I
> > defined: a stable branch synch'ed with 5.0 head with extra backports Tiny
> > doesn't want
ok, most reply's support a new stable_bugfix branch.
Some additional questions that needs an answer i guess;
* Do we maintain the tracker on this branch?
* Do we maintain translations on this branch?
* If community reports bugs, where should they report them? On
current stable or ne
A Dissabte, 23 de gener de 2010, Raphaël Valyi va escriure:
> Sorry, but last counter-example of this is less than 10 minutes ago,
> Syleam vetoing again one more merge proposal:
> https://code.launchpad.net/~openerp-commiter/openobject-addons/trunk-extra-
> addons/+merge/14302
>
> Again, I can't
Hmm, that's also not the case here.
Due to the fact that half of Europe plus many other countries like US
needs this module for stock accounting, it is at least strange that this
merge is rejected by one person.
When the problem did arise and the impact was clear (many countries), FP
jumped int
A Dissabte, 23 de gener de 2010, Jan Verlaan - Veritos va escriure:
> Hmm, that's also not the case here.
> Due to the fact that half of Europe plus many other countries like US
> needs this module for stock accounting, it is at least strange that this
> merge is rejected by one person.
> When the
: [Openerp-community-leaders] Simple things we need from Tiny for
better bug planning/management
On Sat, Jan 23, 2010 at 3:21 PM, Albert Cervera i Areny
mailto:alb...@nan-tic.com>> wrote:
A Divendres, 22 de gener de 2010, Raphaël Valyi va escriure:
> 2) I see that some of you mor
Hello Savyn,
2010/1/23 Savyn Vydelingum
> Hi Raphaël and Everyone,
>
your mail was private but from the greeting I think it was actually meant to
be public, so did I (may be you are not part of the list, which seems
reasonable if as Tiny wanted we want to restrict it to people having a
certain
haël Valyi [rva...@gmail.com]
Sent: 23 January 2010 20:58
To: Savyn Vydelingum
Cc: openerp-community-leaders@lists.launchpad.net
Subject: Re: [Openerp-community-leaders] Simple things we need from Tiny for
better bug planning/management
Hello Savyn,
2010/1/23 Savyn Vydelingum
mailto:sa...@publicus-sol
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/01/10 21:06, Jan Verlaan - Veritos wrote:
> Hmm, that's also not the case here.
> Due to the fact that half of Europe plus many other countries like US
> needs this module for stock accounting, it is at least strange that this
> merge is rejected
On Saturday 23 January 2010, Raphaël Valyi wrote:
> Sorry, but last counter-example of this is less than 10 minutes ago,
> Syleam vetoing again one more merge proposal:
>...
Some, totally subjective, thoughts:
- Patch rejection is good. I've enjoyed working in projects where a patch will
be reject
Hi all,
Just another example I want to point out:
I proposed a merge correcting the database issues in non locale environment
on the 12th of January:
https://code.launchpad.net/~sharoonthomas/openobject-server/patchfor_postgressql_environnonutf8/+merge/17222
The merge is approved and status chan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/01/10 11:34, Sharoon Thomas wrote:
> Hi all,
>
> Just another example I want to point out:
>
> I proposed a merge correcting the database issues in non locale environment
> on the 12th of January:
> https://code.launchpad.net/~sharoonthomas/ope
Christophe,
I had clearly mentioned its NOT ABOUT KARMA for which nobody in this
discussion/list cares the least bit.
I trust your answer and if I do it then the question is:
You(Tiny) wasted time and effort fixing something which was already fixed
and requested for a merge
The bug was opened o
Sharoon,
i think you hit with your doubts the hart of this discussion. At least
several community members I spoke in the Netherlands have the same
doubts together with most of the others here in the mailinglist.
The rest of the discussion held is about a possible solution to overcome
these dou
Jan Verlaan - Veritos wrote:
i think you hit with your doubts the hart of this discussion. At least
several community members I spoke in the Netherlands have the same
doubts together with most of the others here in the mailinglist.
The rest of the discussion held is about a possible solution t
Hi !
I agree with Jan Verlaan, The best solution is that the community has the
commit right on the main stable branch. The official release is just a tag on a
specific revision. Other project Open Source are running like this for years
now, and it works well as long as things are discussed !
50 matches
Mail list logo
