Re: [Openerp-community] Towards a contributor agreement for OpenERP

2011-07-28 Thread Sharoon Thomas
 sustain the growth of the open source product.

Even if you don't do any of the above, please stop bluffing your community and 
that would be good enough. It was you who said that you wouldn't double 
license, and then you changed your own words. If it was a mistake, show the 
boldness to say you were wrong. I can completely understand if you say OpenERP 
SA is a for profit venture, we have to make money and hence we are looking at 
alternate strategies, but bull***ing the community about a semi proprietary 
license (which does not even seem legal) which you could use to your own 
advantage is total nonsense. 

 
 I saw so much good contributors going not open when starting to talk about 
 money (axelor, sharoon, pragtech, ...) 

I speak for myself and Openlabs [8] here

1. I guess you still haven't read this GPL FAQ entry [7] while you were 
searching for all your loopholes to make your exception license. GPL allows you 
to SELL COPIES and we are doing just that. 
2. Why do you freak out every time you see someone other than openerp SA and 
its partners sell their services and OpenERP related products ? 
3. We made a UPS integration module [9], sold copies under GPL and on 
recovering our target, released it free as in free beer all the while we were 
selling it, it was under GPL free as in freedom. You once said that such 
shared funding development never works, and it never worked for you because you 
were greedily selling it for years telling you never recovered the costs. (FYI: 
In-fact most of the customers of the UPS module were your own partners, figure 
it out with them...). 

 That's why I am afraid to give a copyright to that kind of people that could 
 lock OpenERP in the future.  I don't trust everyone, but i trust myself. 
 OpenERP already prooved that it's not our case. 

I simply don't understand why you have two stands when it comes to making money 
- 
1. You have your proprietary migration scripts for an AGPL software which you 
have not published yet and you make money from it ? I am keen to understand 
why this is right while we are wrong. Is it because you had an exception 
fabricated for yourself or is it because they were not good contributions. 
2. Also your website talks about an OpenID module and you seem to be hiding the 
code in your internal launchpad repository [10]. Which customer's 
competitiveness is lost if that is also covered by your so called AGPL 
exception ?

Why is it fair when you do it with all the lying and denying, while wrong when 
we just do something which is legal, compliant with GPL and standing by it? 
And if you still don't understand that free stands for the 4 freedoms (0 to 
3)[11] (which each of our customers get when they buy software from us), I can 
simplify it to we will continue to develop GPL and AGPL modules and continue 
to sell them. Fell free to sue us (address below [12]) if you think its 
illegal, otherwise stop creating FUD around the same. 

You should definitely be scared of my copyrights as I will NOT ALLOW MY OPEN 
SOURCE CODE to be used in a LOCKED SERVICE and the only company I know will do 
that is OpenERP SA. It is very unfortunate that you have more than 7 certified 
modules with my copyright (if you haven't removed them already).


 So I think the contributor agreement is important for the future. (or the 
 public domain which is the solution I prefer for simplicity)

hmm, good joke about simplicity! 
+1 for a contributor agreement which makes sense

 
 
 In order to satisfy your fears, we can investigate the solution of raphael:
 
 we can put a clause on the contributor agreement: if one day, something 
 developed by openerp is not open source (under one of the gnu licenses) the 
 copyright goes back to the community. I do not know the legal impact of such 
 a thing but it's clearly in phase with what we want to do with OpenERP.
 
 If it's legaly possible, this is something I like as it could satisfy 
 everyone and avoid more misunderstanding with OpenERP.
 
 This could be great as I can die while knowing that the open nature of 
 OpenERP is guaranteed in the future :) 
 
 
 -- 
 Fabien
 
 PS: we have been bad in the communication in the past days. don't forget we 
 are a small company with limited resources like most of you. we can do 
 mistake, we will try to improve that.
 ___
 Mailing list: https://launchpad.net/~openerp-community
 Post to : openerp-community@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openerp-community
 More help   : https://help.launchpad.net/ListHelp

In short, OpenERP was a great project and could still be a great project with a 
good leader. 
Fabien™ 0.2 (or is it 6.0) seems corrupt , buggy and has significant memory 
leaks [13]. OpenERP SA ® 0.2 seems to have rounding issues with anything and 
everything from licenses to copyrights [14]. 
Please revert or some people might upgrade to tryton . 


Thanks,

Sharoon Thomas
Software Architect and CEO

Re: [Openerp-community] [Fwd: Re: Injustice, plagiarism and insult of community work]

2010-10-25 Thread Sharoon Thomas
Hello Fabien and Mantavya Ji,

I would like to thank you for merging poweremail into the openobject addons
6.0 [1] and for fixing the copyright issues [2].

I support the idea of splitting the module into multiple feature based
smaller modules. However, in the forking process, you have missed some of
the features like [3] and also the quality improvements in the refactoring
effort [4] we made. We could propose the changes as merge proposals or
patches.

[1]
http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/files/head:/email_template/
[2]
http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/revision/3164.125.11
[3] https://bugs.launchpad.net/openobject-addons/+bug/656897
[4] https://code.launchpad.net/~sharoonthomas/poweremail/refactoring

Thanks,

On Thu, May 20, 2010 at 1:20 AM, Sharoon Thomas
sharoontho...@teagarden.inwrote:

 Hello Sir,

 Thanks for this interesting long fabricated mail.

 On Wed, May 19, 2010 at 6:07 PM, Mantavya Gajjar m...@tinyerp.com wrote:

 Hello to All and Sharoon,

 I am Mantavya Gajjar - (mga), Director Tiny ERP India,

 Sorry for my Late Reply, but I just came to know about this email
 chaining from some of the employees.


 I would prefer to believe it, but its very very bad that even senior most
 employees of Tiny don't participate in the community mailing lists.Clearly
 shows why there is a disconnect between Open ERP and the community * [I
 would recommend you to join atleast the framework-expert list.]*


 I had posted a bug that doesn't mean that I am aware about the complete
 product.

 For the bug post, https://bugs.launchpad.net/poweremail/+bug/428568, I
 have seen some of the template screen somewhere on the blog and I see
 some of the notation like ${ } from the screen I did not know that you
 have used mako template.

 I have a sense that if you use features of the mako template then its
 not easy to change the behaviour of parsing the same, and that is the
 reason, that after your reply I did not post any comment on the same
 bug. Actually I should not post the bug but I post because at that time
 I was crazy about the new development I did and that as the Server
 Action. (In that if you look at the Email  SMS Action features i use
 the notation [[ ]] same like OpenERP report to parse the object /
 fields). the Intention behind this post was to keep the same notation
 [[ ]] instead of the ${}. at that time I didn't know that this post will
 prove me liar.


 Wrong argument about mako, but I prefer to believe you on the rest.


 Regarding the Powermail - after listening India Director has to lie I
 try to check the poweremail module and try to check the code.
 (
 http://bazaar.launchpad.net/~openerp-commiter/poweremail/poweremailtrunk/annotate/head:/poweremail_core.pyhttp://bazaar.launchpad.net/%7Eopenerp-commiter/poweremail/poweremailtrunk/annotate/head:/poweremail_core.py)
 at the first look it seems more or less the Axelor Webmail module. which
 manage Inbox, of emails, provide the templates for emailing.


 I want to believe that you never checked poweremail before. Axelor webmail
 module (If its the open one in the standard repos) is just not even a
 quarter of poweremail -it just downloads mail and as far as i see does not
 have powerful templating or such reception with read/unread status etc.



 Regarding the Fetchmail: As I have already informed to Fabien during his
 trip to Indian, that why I have invented the fetchmail module.

 - To replace the mail_gateway module which was tightly coupled with the
 crm module (even after migration from email_gateway.py script to
 mail_gateway module)

 - From the beginning I have already Invented the smtpclient module in
 the trunk-extra-addons, and it is alternative of the tools.send_email()
 (I think this module I have developed before the Sharon's Training @
 Indian Office, I think Sharon I have shown you this module during the
 Training).


 Yes, you did show the module, but it never worked and that's where I got my
 first dose of inspiration for poweremail. If you remember we had an argument
 then about the 'lockin' disadvantage of having such a system.


 - Before 1.5 months Tiny ERP Indian office have started the recruitment,
 and due to that we are getting lots of CV's I want some system where i
 can redirect this all emails to our Internal Interview Module (which is
 already running in our system), for that I required some system like CRM
 Mail Gate. but I was not able to use the same as its strict with CRM
 module. so one of the biggest reason was to develop a Fetchmail was
 this

 So, finally I started to work on that and come with the very simple
 module by taking the email_gateway module code I prepare a generic and
 very simple system which can be used in any module (yes of course need
 to write 2 method in the model which we want to integrate).


 If you had used poweremail the job would have been done in 5 minutes. After
 1.5 months you still dont have a working solution... lol

Re: [Openerp-community-leaders] [Openerp-community] [Fwd: Re: Injustice, plagiarism and insult of community work]

2010-05-19 Thread Sharoon Thomas
 Fetchmail was
 published in the addons branch. but that is again not a relation of
 fetchmail with the poweremail module.


My company site says as you have quoted good news ... If I was angry I
would have written Bad news? I dont understand what you try to explain
here!



 Also, I have reviewed Axelor Webmail for so many times( At Indian
 office), also gives the solution for some problems, do you think that I
 need to copy and paste from the Powermail module ??


I have personally taken my training from you and I completely understand
your skills in programming and knowledge. There's no question about it. I
respect your knowledge and skills but replicating functionality is no excuse
for it.



 Working with the sms  email applications is interesting things for me.
 http://sites.google.com/site/mantavyagajjar2/massmailing-java
 http://sites.google.com/site/mantavyagajjar2/massmailingapplication
 http://sites.google.com/site/mantavyagajjar2/smsapplication

 - and that's why I put 2 module on the trunk extra addons (smsclient,
 and smtpclient as smsclient nobody is using so there is no enhancements
 smtpclient used by the 2 major projects webmail and direct marketing
 project - dm)

 you have no rights to blame anyone before knowing the complete truth,
 how come you say that its 90% same in the code and 99% same in logic?


As mentioned my reasons for the above claim are below:

Reason 1: HTML2TEXT in poweremail is in separate file, in your module in the
same file

Reason 2: 9/13 fields already exist in poweremail core accounts (obviously
the views have similar structure)
[Format: fetchmail_field:poweremail_field]
1.name:name
2.active:
3.state:state (with three equivalent states)
4.server:iserver
5.port:iport
6.type:iserver_type
7.is_ssl:isssl
8.user:username
9.password:password
10.action_id:
11.object_id:
12.priority:
13.user_id:user

Reason 3:

Constraint of check_duplicate in fetchmail: Called _constraint_unique in
poweremail

Reason 4: Method similarity [4/5 methods are same]

_process_email :
set_draft : done in workflow
decode_header : decode_header_text
button_fetch_mail : send_receive
fetch_mail : get_mails (Almost the same in code as well with same kind of if
else logic)

When a model, view and methods are same in functionality, I prefer to call
it a duplicate. Now tell me why I cant make the above claim. (Sorry if its a
rounded percentage.. lol)
If you call 'apple' an 'Apple', python may be case sensitive and make a
difference but doesnt make it new code.



 I would like to request any community member to check out the code of
 both the modules. I would not like to enter in a huge discussion.


I have made it easy for the community member who wants to check.



 We appreciate your contribution in the community, but you should
 respects others too.


With all due respect to you as an Individual, I should say that I am
convinced that you will neither accept the fact that you copied, nor do I
expect you to. Open ERP SA claims to support all community work. Can you
give the name of the community modules which you have contributed to
officially and incorporated to the official base? Do you want to say that
till today there are no valid contributions from the community?

I know you hate this name 'Tryton', please download its client (from
www.tryton.org) and have a look at the 'About section'. That will show you
the 'respect' an opensource project should have for its contributors. To get
what you have made today all what you needed was to add 4 fields to
poweremail, but i want to believe you never knew about 'poweremail'.

Everything about your reply is so contradictory, and despite the nice laugh
this mail gave me at the end of tiring day (thankful to you for that), I
would like to stop this mail trail. I am convinced that you will never
accept the truth and I have no time to keep proving your false statements
false.

Remember that what Open ERP SA is today is not what your copyright claims it
to be, its what your partners and the community makes it to be. The day is
not far when the competition you try to deny (Tryton) will be much ahead in
popularity as well, it already crossed to be a better framework than Open
ERP when you guys were busy trying to have SQL Alchemy inside Open ERP ORM.
I have a humble request: Please dont insult Tryton then by adding it to your
manipulated http://evaluation-matrix.com/

Apologies if I have been a bit out of topic, but I guess it is necessary for
you to understand because you seem to be too disconnected from the real
world (from the fact that you are not on any such mailing lists or
communication channels and never even knew about a popular community
module's functionality after a presentation was conducted in you head
quarters).




 Regards,
 Mantavya Gajjar
 Director
 Tiny ERP Private Limited


 On Sun, 2010-05-16 at 15:44 +0100, Sharoon Thomas wrote:
  Hello Fabien,
 
  Thanks for this update as well.
 
  Its very unfortunate that your India Director has to lie

Re: [Openerp-community-leaders] [Openerp-community] Injustice, plagiarism and insult of community work

2010-05-15 Thread Sharoon Thomas
Hi Fil,

You are right!
But thats the official website of Open ERP India. Its a direct link to their
website.

So if there is a trojan, its on their site.

I have copied this mail to the right people who can correct that.

Cheers!

On Sat, May 15, 2010 at 10:00 AM, office off...@filsystem.ro wrote:

  If what you say is true, then you're right to be angry. But, please be
 careful with links in email or forums because your link
 http://blog.openerp.co.in/?p=400 from your mail is infected with JS /
 Agent Trojan NCA.
 Thanks,
 Dumitru Gilcescu
 Fil System

  *From:* Sharoon Thomas sharoontho...@teagarden.in
 *Sent:* Saturday, May 15, 2010 2:54 AM
 *To:* Fabien Pinckaers f...@tinyerp.com
 *Cc:* Openerp Expert Frameworkopenerp-expert-framew...@lists.launchpad.net; 
 Stephane
 Wirtel s...@tinyerp.com ; openerp-commun...@lists.launchpad.net ; Varun
 Kumar varun.ku...@openlabs.co.in ;
 openerp-community-leaders@lists.launchpad.net
 *Subject:* [Openerp-community] Injustice,plagiarism and insult of
 community work

 Hello Fabien and the Open ERP community,

 I request your attention to this post dated 2nd of May:
 http://blog.openerp.co.in/?p=400

 It is a clear duplication of work done by Open ERP SA on the community
 module 'Powerwmail' .

 I am not surprised but shocked to see this trend repeating again and again.
 Why is it that the community ideas have to reinvented by Open ERP SA in a
 different name everytime? It happened with scenario, rml and now I think it
 is right time to question whether its the right ethics for an opensource
 project ? To retain the copyright on the Open ERP code Open ERP SA goes to
 any extend?

 I understand that it is Open ERP business model that 800EUR (or may be more
 because of the heavy code) is what is needed for a module to be 'certified'.
 Is it because the community cannot pay for a community contribution that the
 effort is duplicated? Well I think contribution of such useful features
 itself makes openerp more that worth 800EUR because till today I have
 received numerous mails saying how the work saves every developer couple of
 days. This is strongly disappointing for any community contributor. What is
 the point in releasing the code if it is next day going to be duplicated by
 your paid employees? What is the point of the community if the credits are
 all for open ERP SA?

 I draw the attention also to the commitment made by fabien and antoine at
 the community days in Belgium to all those present there that poweremail
 would be drawn into official 6.0. I request you to respect the community and
 your own words.

 Have a look at the duplicated work:
 http://bazaar.launchpad.net/~openerp-commiter/openobject-addons/trunk-mod3-local/annotate/head:/fetchmail/fetchmail.pyhttp://bazaar.launchpad.net/%7Eopenerp-commiter/openobject-addons/trunk-mod3-local/annotate/head:/fetchmail/fetchmail.py
 The model structure is 90% similar. Logic is 99% similar.

 I wonder why you could not contribute if there is anything that's not there
 to the main poweremail code which is open to everybody to edit. (
 https://code.launchpad.net/~openerp-commiter/poweremail/poweremailtrunkhttps://code.launchpad.net/%7Eopenerp-commiter/poweremail/poweremailtrunk
 )

 I wish you spend your resources and time on playing the fair editor of an
 opensource project. Not Micro$oft of the opensource world. I may not waste
 my time on fighting legally or morally for the sake of poweremail again, but
 be sure that community members will also soon realise that contributing to
 openerp is waste of time. Who knows if their work will be duplicated by the
 editor in the next release. You discourage contribution to openerp and I
 speculate the intention of open ERP SA in holding the copyright of the code
 whatever they need integrated into the core.

 When I conclude this mail, I am not sure if I will ever get a reply for
 this mail from 'Open ERP SA'. But please remember that the more you do this,
 the more the community moves away from you.

 Wish you good luck plagiarising!

 and a simple advice to your Indian team doing all the duplication work:
 Atleast show the quality of code poweremail has in your duplicated work. I
 can already see several logical foolishnes in your code and absolute '0' in
 code quality. Atleast try making something better with all the TODO's that
 has been left in the code.

 Thanks,
 --
 Sharoon Thomas
 Business Analyst  Open Source ERP Consultant
 CEO @ http://openlabs.co.in

 --

 ___
 Mailing list: 
 https://launchpad.net/~openerp-communityhttps://launchpad.net/%7Eopenerp-community
 Post to : openerp-commun...@lists.launchpad.net
 Unsubscribe : 
 https://launchpad.net/~openerp-communityhttps://launchpad.net/%7Eopenerp-community
 More help   : https://help.launchpad.net/ListHelp



 __ Information from ESET NOD32 Antivirus, version of virus
 signature database 5115 (20100514) __

 The message

Re: [Openerp-community] Injustice, plagiarism and insult of community work

2010-05-15 Thread Sharoon Thomas
Hi Fil,

You are right!
But thats the official website of Open ERP India. Its a direct link to their
website.

So if there is a trojan, its on their site.

I have copied this mail to the right people who can correct that.

Cheers!

On Sat, May 15, 2010 at 10:00 AM, office off...@filsystem.ro wrote:

  If what you say is true, then you're right to be angry. But, please be
 careful with links in email or forums because your link
 http://blog.openerp.co.in/?p=400 from your mail is infected with JS /
 Agent Trojan NCA.
 Thanks,
 Dumitru Gilcescu
 Fil System

  *From:* Sharoon Thomas sharoontho...@teagarden.in
 *Sent:* Saturday, May 15, 2010 2:54 AM
 *To:* Fabien Pinckaers f...@tinyerp.com
 *Cc:* Openerp Expert Frameworkopenerp-expert-framew...@lists.launchpad.net; 
 Stephane
 Wirtel s...@tinyerp.com ; openerp-community@lists.launchpad.net ; Varun
 Kumar varun.ku...@openlabs.co.in ;
 openerp-community-lead...@lists.launchpad.net
 *Subject:* [Openerp-community] Injustice,plagiarism and insult of
 community work

 Hello Fabien and the Open ERP community,

 I request your attention to this post dated 2nd of May:
 http://blog.openerp.co.in/?p=400

 It is a clear duplication of work done by Open ERP SA on the community
 module 'Powerwmail' .

 I am not surprised but shocked to see this trend repeating again and again.
 Why is it that the community ideas have to reinvented by Open ERP SA in a
 different name everytime? It happened with scenario, rml and now I think it
 is right time to question whether its the right ethics for an opensource
 project ? To retain the copyright on the Open ERP code Open ERP SA goes to
 any extend?

 I understand that it is Open ERP business model that 800EUR (or may be more
 because of the heavy code) is what is needed for a module to be 'certified'.
 Is it because the community cannot pay for a community contribution that the
 effort is duplicated? Well I think contribution of such useful features
 itself makes openerp more that worth 800EUR because till today I have
 received numerous mails saying how the work saves every developer couple of
 days. This is strongly disappointing for any community contributor. What is
 the point in releasing the code if it is next day going to be duplicated by
 your paid employees? What is the point of the community if the credits are
 all for open ERP SA?

 I draw the attention also to the commitment made by fabien and antoine at
 the community days in Belgium to all those present there that poweremail
 would be drawn into official 6.0. I request you to respect the community and
 your own words.

 Have a look at the duplicated work:
 http://bazaar.launchpad.net/~openerp-commiter/openobject-addons/trunk-mod3-local/annotate/head:/fetchmail/fetchmail.pyhttp://bazaar.launchpad.net/%7Eopenerp-commiter/openobject-addons/trunk-mod3-local/annotate/head:/fetchmail/fetchmail.py
 The model structure is 90% similar. Logic is 99% similar.

 I wonder why you could not contribute if there is anything that's not there
 to the main poweremail code which is open to everybody to edit. (
 https://code.launchpad.net/~openerp-commiter/poweremail/poweremailtrunkhttps://code.launchpad.net/%7Eopenerp-commiter/poweremail/poweremailtrunk
 )

 I wish you spend your resources and time on playing the fair editor of an
 opensource project. Not Micro$oft of the opensource world. I may not waste
 my time on fighting legally or morally for the sake of poweremail again, but
 be sure that community members will also soon realise that contributing to
 openerp is waste of time. Who knows if their work will be duplicated by the
 editor in the next release. You discourage contribution to openerp and I
 speculate the intention of open ERP SA in holding the copyright of the code
 whatever they need integrated into the core.

 When I conclude this mail, I am not sure if I will ever get a reply for
 this mail from 'Open ERP SA'. But please remember that the more you do this,
 the more the community moves away from you.

 Wish you good luck plagiarising!

 and a simple advice to your Indian team doing all the duplication work:
 Atleast show the quality of code poweremail has in your duplicated work. I
 can already see several logical foolishnes in your code and absolute '0' in
 code quality. Atleast try making something better with all the TODO's that
 has been left in the code.

 Thanks,
 --
 Sharoon Thomas
 Business Analyst  Open Source ERP Consultant
 CEO @ http://openlabs.co.in

 --

 ___
 Mailing list: 
 https://launchpad.net/~openerp-communityhttps://launchpad.net/%7Eopenerp-community
 Post to : openerp-community@lists.launchpad.net
 Unsubscribe : 
 https://launchpad.net/~openerp-communityhttps://launchpad.net/%7Eopenerp-community
 More help   : https://help.launchpad.net/ListHelp



 __ Information from ESET NOD32 Antivirus, version of virus
 signature database 5115 (20100514) __

 The message

Re: [Openerp-community-leaders] Simple things we need from Tiny for better bug planning/management

2010-01-24 Thread Sharoon Thomas
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 changed to merged by an open ERP employee
yesterday with a comment that the patch is good but has already been fixed.
The fix link is here
http://bazaar.launchpad.net/~openerp/openobject-server/5.0/revision/c...@tinyerp.com-20100120163913-5ftbs7e85lwqb1et.
I am happy that its fixed, but the author is different and NOT WHEN I
SAY
THIS I AM NOT DYING FOR CREDIT OR KARMA.

I just want to point out that I dont see a single community contribution (if
any like the one above they are made the editors') in the closed branches of
Tiny (server  'Certified' Addons).

Somebody please clarify my doubts:

   1. Is it because tiny wants to retain the ownership of the code of the
   server  addons, but benefit from all the community contribution.??
   2. I understand its possible to change the license of a project if the
   code base is completely owned by the changer. I am not a license geek,
   somebody who knows please clarify. I dont want to be pissed off by any
   company like the hundreds of open source projects did to their community.
   3. The recent marketing efforts may have been seen positively by many. I
   try to convince myself as well but i dont get convinced. It looks more to me
   like Sun (Or Oracle to be precise) is going to invest in Tiny? Everybody has
   intentions behind every penny spent. Definitely they are going to push for
   MySQL or probably Oracle being used with ERP? The recent madness and
   obsession shown by Tiny in the SA branch sort of reassure me of this. More
   here http://www.bloomberg.com/apps/news?pid=20601204sid=a0Wy0DITQBiA
where FP says he wants to sell the company off (forget the time
period, why
   would he not do it if he gets a better offer now???) What about the major
   vendors having purchased 90% of the top Linux kernel developers and many
   of the developers of important frameworks like GNOME or KDE? Isn't this
   to give them more control on where such technologies are evolving? Isn't
   Canonical's purchase of a significant number of Debian developers
in the same
   vein? 
(sourcehttp://www.joachim-breitner.de/blog/archives/60-Launchpad,-Google-and-why-Microsoft-is-not-the-problem.html
   ).

I have enough reasons to believe in the above and moreover i see more people
who think alike...
If Tiny doesnt respond to this also then what will they ever respond to

To FP: these are not accusations but just doubts and concerns that are in my
mind. I believe there's no better forum to clarify.

Sharoon Thomas

On Sun, Jan 24, 2010 at 8:54 AM, P. Christeas x...@hellug.gr wrote:

 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 rejected if there is a spelling mistake in the commit description. That
 keeps quality standards high.
 - Patch acceptance shouldn't be driven by personal favours (I like that
 partner, I accept their patches..) or we screw the project.
 - Extra addons may be the way to go. Perhaps, one huge repo for both
 mature,
 essential addons and those that have partial use, will always keep us in
 versioning dillemata. In fact, 5.2 supports multiple addons paths,
 remember?
 OTOH, when an addon moves from extra to normal, it's hard to preserve
 its
 source versioning history, bad. Surely, non-trivial.

 - Notice that I'm talking about /patches/.


 ___
 Mailing list: https://launchpad.net/~openerp-community-leaders
 Post to : openerp-community-leaders@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openerp-community-leaders
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openerp-community-leaders
Post to : openerp-community-leaders@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openerp-community-leaders
More help   : https://help.launchpad.net/ListHelp


Re: [Openerp-community-leaders] Simple things we need from Tiny for better bug planning/management

2010-01-22 Thread Sharoon Thomas
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. Yesterday we see that
xavier(xmo) is working on the same thing and repeated the same lines of
code.

If quick merge reviews and commits dont happen into the closed branches
maintained by tiny then it will definitely lead to maintaining our own
branches and eventually tiny spending time (and money) on developing the
same features/fixes in community maintained branches.

OERPScenario is a great idea! but all this will be in vain including this
discussion if its not attended to by Tiny.

-- 
Sharoon Thomas
Business Analyst  ERP Consultant


2010/1/22 Joël Grand-Guillaume joel.grandguilla...@camptocamp.com

 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 most important point are:

 - As Ferdinand said, Tiny and any other MUST comply to legal and audit
 (pear review).
   A good and trustable Open Source project is one where topics, features
 and bugfixes
   are discussed.

 - Let the community express their self on how and what to include or not in
 the stable release !

 - As Rvalyi said we need to be able to plan the bugs on release and
 milestones.
   Tiny must respect the release dates, otherwise, we just waist time.

 - Tiny must make the effort to review the merge proposal more efficiently,
 and details
   why they refuse a proposal

 - Running OERPScenario before any commit on addons/account or server ;) !
 Even better :
   Write a test case for each high/critical bugs found !!! Just with 6 tests
 cases for now, I already
   found 8 critical's regressions in accounting, rounding and currency
 trouble.


 We have our own branch, just because we can't trust Tiny's commit and it's
 very sad ! This
 allow us to test things before we merge from their official branch...
 Ensuring our customer not to
 have big trouble...

 A review process for everyone is the key point for me.

 Regards,

 Joël


 P.S. May be a community branch is better than 6 partners branches if Tiny
 won't change something




 Le 21 janv. 2010 à 11:34, Albert Cervera i Areny a écrit :

 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) our super-stable release merged into the official stable release.

 From marketing perspective we have a issue too, which release to choose

 for implementations? The official or the community version?

 making a differentiation here is the first step in a forking cycle, it

 is just waiting for the next step.


 So it would be better to have a tough discussion with Tiny how to

 overcome the problems we face as a community. There must be a way where

 we can work together on the same stable version. It is of both interest.

 If it's not of interest of Tiny, then we have an serious issue and the

 discussion about maintaining a own branch is legitimated. But actually

 that is called forking, isn't it? We just name it different!


 Hope Tiny will jump in in this discussion.


 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 lots of individual branches (Raphaël made a list of them).
 Maybe a
 community branch could avoid many of those branches (again I'm not sure

 about that).


 Op 21-01-10 10:06, P. Christeas schreef:

 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 this, but sometimes not being able to fix

 some things really slows things down. We currently can get faster

 (better?) feedback from these new mailing lists than from Tiny (they

 have their resources and priorities which I understand).


 In short:

 Technically, thec current process of manipulating openerp patches +

 branches is far from optimal. That must be a major part of the problem,

 but still is not that alone .

 The human collaboration is the other part of the issue. This community

 has expanded rapidly, and we may be in a state of ad-hoc collaboration.

 For me, there is a strong human factor in that, in the sense that

 developers need to trust each other and know what