openerp-community-leaders team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

On Fri, Jan 22, 2010 at 3:27 PM, Ferdinand Gassauer <office@xxxxxxxxxx>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 nobody here thinks there is one mysterious "Jay" that has such a
high Karma and does a lot of Stakhanov bugfix. Actually Jay is only on of
the Tiny India managers and there is an army of cheap Indian monkeys behind
him that know more or less how to patch the stuff and give the work/analysis
back to him and eventually a fix is commited/message answered.

The reason why those Indian developers are not exposed publically is at
least strange and I never liked that. It's like they fear their guy would be
hired eventually. I think a fair business is you claim to offer the best
conditions to your guys so they stay with you, other kind of strategies are
strange, especially when you get the private feedback we sometimes get from
those developers. Or ask Sharoon Thomas, the guy that was trapped in such a
situation in India, but succeeded to make its way out fortunately. I think
open source is all about being fair. You should succeed because you are
good, not because you are a despot, else it can even lower the overall
quality.

It's not us who should tell how Tiny or Axelor should manage their
guys. Personally, I just prefer that things are transparent with possibly
real guys and real Karma.
When you know how it is and you see that it seems that some of those
management guys claim to have high Karma such as:
http://74.125.113.132/search?q=cache:lz0FgnelsacJ:openerp.mantavyagajjar.co.cc/+mantavyagajjar+openerp+ohloh&cd=1&hl=pt-BR&ct=clnk&gl=br
(see ohloh.net logo on the right) While it's actually the work of others
that are given no opportunity and call us privately to tell so, I just don't
think it's great.

That being said, I think Jay does his work well, no problem with that. I
just wanted however to give a few facts for those of you that may be
mistaken, though I actually doubt you are, let's say just in case.


Now, back on the fundamental problems:

1) Yes I agree to say things have improved steadily and continue to improve.
So there is hope fortunately. But also I understand we possibly can't afford
waiting so long to get the important fixes/refactoring before next glacial
area freeze.

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: Tiny continue to be the authority telling indirectly what could
be in or not.
Now, given how slow is the merge process on trunk, unless Tiny can change
it, it doesn't sound it would solve the speed issue.

Now, if we say we accept patches on that branch that are not trunk
backports, well, unfortunately, I doubt decision will be that easy. Yes I
suggest to make that branch eventually, but only if we can agree on policies
like voting or something like that.

The analysis of the recent patches show us that even among partners advanced
users we do not always agree:
- I had that fully baclkward compatibible + test merge on 5.0 vetoed by
Syleam:
https://code.launchpad.net/~openerp-commiter/openobject-addons/account-method-extraction/+merge/15727
- and I also believe that Syleam again was against deprecated XML removal
for Ubuntu compatibility in 5.0.x branch.
I those case, I mean, that's OK, we can perfectly disagree on some point and
I don't hold on Syleam for this, but I just want to illustrate that, if
branch X is more than just a set of possible backports (and even if it is),
then decision policies has to be taken.

I suggest in similar case, we have a voting system, eventually ponderated
with Karma or anything better than nothing. Thus, in such a case, if you
have the votes, then the merges passes even if someone doesn't like it (as
long as it's really an isolated opposition), I mean we don't just pass with
50% majority.
The guys who don't want the patch, then take the responsibility to maintain
their own non patched branch, I think that's way better than a minority of
folk be able to lag the majority just because for some customer X, they
don't want to make a test or execute some one liner SQL to get the overall
code quality increased and done in a sustainable way (eg when serious guys
work for real customers).


At some point this is what is happening with Tiny: at some point they don't
want to make any extra testing effort/migration effort because of third
party contributions, no matter the long term improvement it embodies. On one
side, I admit Tiny have the right to force that asymetrical relation (they
don't suffer third party regression but third parties like us suffer Tiny's
regressions eventually, remember the report thing?) because they made
OpenERP like nobody else did (not alone, but they did way more than anybody
else) and they continue to invest on it way more than anybody else.
So that's sad, but that's fair. Now, if a branch system + commit policy can
make all our life easier, then I'm in.



3) At some point, I think there is a deep marketing implication. Tiny wants
to market OpenERP + Odoo as a mature out of the box offer (else they
wouldn't sale any, right?). Well, all of us know it's not the case (though
hopefully it could turn a self fulfilled prophecy in 6 months/1 year), we
all think any serious install requires dozens of day of tweaking and bug
fighting to be really usable, right? I remember, I've been annoyed in the
past by Ana Juaristi coming in the forum and telling us, hey look, no, we
are actually smarter than you, because we are able to do 5 days install!
Well, fortunately, after doing a few real installation they now don't have
that kind of attitude anymore and I think that's a great step toward a
decent quality for customers. We really don't need such jokes.
And unfortunately there are still a few jokers around:
http://www.openerp-france.fr/
http://www.synerpgy.fr/

Because Tiny makes such marketing now, they can't indeed afford releasing
more often or having backward incompatible fixes. That's sad because there
is a lot of decisions that have been taken really too fast in OpenERP
codebase and only backward incompatible changes can fix them (I'm
not denying here the superiority though of that codebase compared to other
open source ERP's). If one year is the only time period to get a backward
incompatible changes in, then it's really bad because:
- meanwhile a lot of modules will develop on a very weak basis
- it's damn slow, some fixes will possibly have to wait 3 years to enter due
to the fact everyone has his own schedule and the probability of a match for
the unique yearly opportunity can easily be missed.

I don't think, and I'm sure you agree, that OpenERP is that mature. I think
that the only real success stories so far required a lot of work by very
skilled people to be achieved. So, in the real life, I think those real
people with that real work, are perfectly able to do one SQL command or do
one test in between two official major yearly releases. Actually if doing
that very little extra effort was the price to pay to avoid a ton of bug
that indeed force them to tweak their system for days, then I'm sure lot's
of people would agree on that non demagogic position.

Now, I agree, this wouldn't please the some investors nor some customers.
But if he quality is so low anyway that those customers can't get any
skilled partner to have their installation because the few aliens around are
all busy, were is the point in fooling everybody with a demagogic marketing?
I mean, regarding the fund raise, I admit this was the only way and a fund
raise is indeed certainly useful at this point. But now, I'm not sure this
position should justify slowing down the whole progress by forcing slow
process that look more stable to anybody WHO DIDN'T TRY IT FOR REAL.



4) Still, even if we start such a branch, for me it doesn't fix the issue:
will our fix be in in the newt 'official release' ? That's a guess. We can
estimate we can create such an attractive branch that it will be merged,
yes. But Tiny might also have the "attitude" of not letting the merge enter
just to feel they were right. You think that's childdish, you don't believe
me? All right, I think the Tryton fork thing is due at 50% to such
"attitudes" issues. Just too bad, being half forced to maintaining a real
fork one year latter would be too stupid, it would be even more stupid than
I we all seem to agree here: only Tiny can have the lemitimity/power to lead
the development. So I'm very open to mutualizing efforts outside from the
official branches if Tiny proves to be unable to do more, but I just want to
avoid that kind of walk (I mean for myself at least).


5) Finally, yes, helping CampToCamp to build a decent testuite with
OERPScenario https://launchpad.net/oerpsenario is a large part of the
solution. Once we have a very good coverage, we and Tiny can be really more
likely to accept patches, even large ones, as they prove not destroying any
feature. So please join the CampToCamp effort, I couldn't be more explicit.
On my side, I contributed no test yet but I spent days polishing OOOR to
help it happen, please read if you are not yet aware of it:
http://www.akretion.com/en/blog/2010/01/18/introducing-ooor---openobject-on-rails-drivingrequesting-your-openerp-became-a-child-play/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+akretion+(Akretion+-+open+source+to+spin+the+world)

Executable tests are really powerful, did you know that the Ruby languages
is going to be certified ISO not because of a document spec but because of
such an executable test suite that defines clearly what it is? (BTW, the
Ruby test suite use frameworks such as RSpec that inspired Cucumber or that
Cucumber can use inside for lower level unit testing).

It doesn't matter if Tiny ignores that Spec until it turns the de facto
standard. Oerpsenario, already can run the Tiny unit test as well, it does
just to a lot more with a decent framework/readability. Nothing prevent us
from running that testuite on some server after each commit. Then, when a
regression is spotted as CampToCamp already spotted like 8, then we just
open a critic bug on their tracker showing them the failing readable case as
CampToCamp did. They will have no choice but admit there own unit test are
not able to spot those regressions while Oerpsenario did it. They will have
no other choice to admit that no third party contributed any functional test
to they unit framework. So yes, they will ending using it and meanwhile,
that's a life saver for us.


All right, enough ranting.

Last minute: there are some good news, read what marketting can achieve:
http://fptiny.blogspot.com/2010/01/sun-openerp-partnership.html


Raphaël Valyi
http://www.akretion.com









>  So TIny makes a big effort compared to some time ago.
>
> for some more complex patches like commit on sequences or rounding
> discussed else where we need to set up a peer review and - may be using the
> test suite OpenERP Scenario <https://launchpad.net/oerpsenario/> (thanks
> to c2c) which must pass running against db using real data (of partners
> and/or typical clients)
>
> And the results should be documented on a per reviewer basis (quality
> control).
>
> * passed
>
> * failed
>
> * not relevant (Example we only use EUR but Camp2camp tests multicurrency
> invoices)
>
>  --
>
> Best Regards
>
> ChriCar Beteiligungs- und Beratungs- GmbH
>
> http://www.chricar.at/ChriCar/index.html
>
> Dr. Ferdinand Gassauer
>
> Official Tiny Partner
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community-leaders
> Post to     : openerp-community-leaders@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community-leaders
> More help   : https://help.launchpad.net/ListHelp
>
>