Including aeroo #1
Comments
|
I think Aeroo can be included into OCA if @sraps is OK about that and signs the CLA. Aeroo covers one need that none of the current reporting engines do: allow fast design by non-tech user. For me, it has served as a cheap way of having custom design reports in OpenERP, because they have it on DOC or XLS. |
Ing. Juan José Scarafía 2014-09-12 11:10 GMT-03:00 Pedro M. Baeza notifications@github.com:
|
|
Well in practice I have several questions and they are not directly Aeroo related, for instance I have other projects as well, so as other's do as well. Passing away just one project without any particular reason, solved nothing. :
IMHO the last one is the most important question of all. At the moment I have no answers to a single one of them. |
|
Great questions, and the answers should be compiled in a FAQ next to a "How to contribute" guideline. |
About 6 and 7: I personally don't think the OCA should be concerned with that, that's up to the businesses themselves. 1-5 tell you why it's still a good idea to join forces. |
|
In general practice things happen like this if everything is ovned and managed by general public without anyone specific in charge:
That is why many of FOSS projects are in essence geek tools, workable still are not turnkey solutions. In my oppinion OCA should focus on maintaining and developing environment of FOSS ERP systems (which are totally different business model than mugware) so that every player feels comfortable, not only the central or end users. Look at any other associations out there, most of them fight for better environment for those involved, none of them fight for better product. In contrast OCA stands for perfectioning product (introduce standards) and trying to push costs down (which is already not so high). Do I (I am speaking for myself) need this? No, I do not put anything of that in a first place. At the moment problem is dog-eat-dog environment while we are supposed to work in technolgy business, but in fact are selling man-hours at lower possible cost. That is why most implementers of Odoo execute policy - rapid deployment (stated 3 months per project !!!), and run. Of course they are fixing some bugs in a way, but 1/1000 gives anything back, not even the ideas or technologies. Only few of the developers "eat their own dogfood". I see no particular practical reason passing Aeroo to OCA:
Concluding, I hope, I could push the movement towards solving real problems - selling the technologies, not patch-man-hours on other's developments, so that everyone involved benefits from the technology not only salesman or end users. And the reward would be really mature product not the patch blanket as it's now. |
|
http://odoo-community.org/page/website.faq Does the Association need money? In essence this means:
Sorry for my sarcasm. |
|
@sraps, I think there is a point a missing point: without OCA, without an organized community, I'm pretty sure things can become pretty worse quite soon (brutal re-licensing, surprise roadmap, obsolescence by design etc...). On the other hand, I also think that OCA will need to provide a fair visibility to module authors. Not unleashed advertisement but serious yet explicit visibility of the work done, possibly including HTML links. By doing so, implementation businesses could certainly get a benefit of image, specially in the high end implementations, that could sometimes replace in part marketing expense of any kind. That is you would get your business value. In fact, if on the contrary OCA dilute authors visibility and incentive users to think it's all for granted, then yes, OCA would instead destroy business value. This isn't sorted out, but I personally wish we deal with these topics with the right amount of balance. May be some big guys of OCA are big enough to afford this to be just a give away. But we should not forget that if OCA goes with no business model at all, it will not attract many guys like you and it will not resist long against the power of money that will make whole different plans for the product. my 2 cts |
|
@sraps, are you aware that we don't need your permission to start an OCA fork of Aeroo (obviously respecting work attribution)? And we will do it if you don't want to join efforts, because as you know this tool is very useful, but I and a lot of people like me don't want to contribute to a personal branch having the possibility to make it under the umbrella of an organization that has also some quality tools and a critical mass that assures the continuity of the project (which you don't). Sorry if I sound rude, but this is my opinion after collaborating with pre-OCA and now OCA for about 2 years. Regards. |
Yes, I am, and that is best and still the worst idea being done every day. There is a huge difference in forking for your personal (in-company) use and forking well promoted software out of interest of polishing one's own image, like you are offering with Aeroo and OCA. If Aeroo is forked by OCA, be aware - at the moment OCA have done nothing so that Aeroo could be further developed, not to mention the efforts invested to promote Aeroo facing Odoo's constant ignorance for the REAL community investing big money in quality software.
I guess OCA shall prove that critical mass, otherwise it looks more like aggressive threatening. I see just OCA saying "pass up or die". Let's face reality, OCA needs projects like Aeroo, the same as Aeroo needs REAL community involvement (not the show of public power) and financing if it's a community project for the community. Otherwise it's just a patchware and will die. I'll make it clear, Aeroo can and shall be used by general public, but it is neither the result of it, nor developed or promoted by charitable efforts - moreover, ERPs are not made by charities. If OCA does not find a way to enforce win-win situation, I see it as some repository for easier and ignorant use by the end no-customer. So that some bigshot can save $$$ not buying expensive proprietary ERP for their multi million enterprise. Yes every enterprises really using ERPs are spending at least hundreds of thousands on software, now it is spent mainly on the software it can not take for granted, for free. I need association to change this de-facto rule, not to take over Aeroo. |
|
Well, that escalated quickly. To get back to the original question: should OCA adopt the Aeroo project? One of the principles of the OCA is to prevent double work. So if Alistek wants to keep maintaining Aeroo by themselves, OCA should not interfere as this would lead to double work. But as with Odoo itself, community contributed bugfixes for sometimes very serious problems have been left for too long on the Aeroo project. So although I'd rather work with Alistek on an OCA Aeroo project, if that is not possible then my suggestion would be to start an Aeroo backports project, along the same principles as the Odoo backports. |
|
@StefanRijnhart Please read the @rvalyi comments. OCA does not fix problems of Aeroo's further development. I admit that there is a space for improvement in Aeroo maintenance, but this is due to the fact that there is mass of users of Aeroo and tiny fraction of contributors of Aeroo. And now all the user and implementer mass acknowledges using Odoo, none of them even bother being aware using Aeroo for generating their daily invoices. OCA does not even put this problem in their scope. This sounds like - give me engine for free, I swear to maintain it well, but maintenance is just part of the life-cycle, you know. Passing Aeroo to OCA saves the day for another ignorant user. |
|
Moreover, there's not even clear who's in charge of OCA, is it a board or a single executive? Somebody responsible, tell me if OCA even wants to maintain Aeroo, dedicate some resources to it? Not even clear if it has such resources - just to maintain. It is wrong by design: "Pass over and we'll figure out what to do then!"At the moment I hear rather aggressive "pass up or die", nobody from OCA board have even bothered contacting me directly and discuss the offer, just some talks in github issues. So, unless something changes, I consider, it's just a bad joke. |
|
@sraps, there is a board in OCA and I suppose they will comment about, but I as a contributor think: I'm not going to contribute to your project where no rules are defined, no quality tools and so on. That's why I'm saying I'm going to fork anyway and see if OCA accepts my "contribution". If not, we continue as is. If yes, people (a lot or very few), will choose surely OCA fork, not your repository, to contribute. Also OCB mechanism, as @StefanRijnhart says, can be another method of forking. I want also a health ecosystem where all the involved people (integrators, developers, Odoo S. A.) can have a win-win situation, but this is another discussion that we already have in other projects. For instance, @Ajuaristi and me are doing a big MRP project. If you pretend to "block" Aeroo entrance in OCA for this discussion, I think this is the wrong way. Regards. Regards. |
|
@pedrobaeza
You are not telling me no news. Many people benefit from Aeroo Reports still few of them cared to give back just a credit that they are using Aeroo Reports. At the moment OCA is a maintainer of their own branch of Odoo, and their own branches of bunch of other software. So what? How does it solves the daily problems of OEM developers? Do they coordinate any new development, that everybody would benefit? So sorry, but OCA solves problems for end-user, not the developer. They get better software at virtually no cost.Please, why do I, as a developer, need OCA? |
|
again, when you say "OCA does not fix problems of Aeroo's further development", IMHO you see the half empty glass. I rather see the half full glass with the fact that OCA can prevent things to be much worse for everybody, including you and Aeroo. And this alone is IMHO a good reason to join forces and leave the FOSS challenges for another round and work them on a company basis meanwhile. Come on, do you think for a sec these pricing things will lead to anything sustainable? What kind of plan B can you imagine after plan A fail? Not so nice, right, so better be pragmatic right now. |
|
@rvalyi When there none responsible, everything just slowly dies. There's not even any idea how to finance the work involved. |
|
@sraps OCA does bring some burbureaucracy, that bureaucracy may certainly be too much for the little module your customer need next week. But for a large project such as Aeroo, in my opinion it's largely balanced by the benefits. I was a bit skeptical too at the beginning, but after some practice I certainly see positive results were we did it. |
|
http://odoo-community.org/page/website.websiteOCA_Benefices Improve your visibilityHow is the visibility improved for any OCA umbrella project? Please name example. At the moment I see no credit of any OEM, other than Odoo itself in the OCA name. It's just one way entry for the OEM, just like with the logo there are no-name ants, not even worth mentioning. Get yourself knownI see no option of even steering my own project. Read above... Go internationalAeroo is already international, it has users in any continent, but Antarctica. Enhance your qualityPlease name example. Reduce your costsOk, it may (potentially) reduce costs of maintenance. Come by legitimacy and sponsorshipAcquire funding supportHow? Please name example. How money travel to the particular people, is there any standard scheme? |
|
@sraps Are you sure about Antarctica? 😄 Seriously, I feel that the discussion has not evolved from Stephan's post onward. It's clear that @sraps doesn't see a benefit in that, and that's OK. So, I think a conclusion has been reached, let's move on. |
|
Yeah, I already have the same feeling a few post ago, so I'll do a PR to reporting-engine project for Aeroo in the next days. Regards. |
@sraps because you get better quality software.
And your words sound to me like "I want to remain the maintainer of aeroo so that people will contact me when they need support" |
|
Well, in essence, let's move to the time where there were no OCA. I contacted to some of then OpenERP community members with similar idea of creating something like OCA. But my primary scope and idea was, finding solution to the problems, practically defining environment around FOSS ERP product and companies working with it. The other thing was to find technical solutions like performance and floating point like problems, in which Odoo SA itself is not interested. Maintenance was the least of the problems. At that moment I was even willing to move some of our projects under incepted association (Alistek has number of projects even lot bigger in codebase than Aeroo is, most of them are lacking of funding, not the hands doing a maintenance), mainly to promote new association. Ok, closer to the idea, scope was solving the problems, not just producing "solutions" to non-existent problems. The idea did not catch up. Two/three years later, at the moment, I see Odoo's 2nd version that is announced as disruptive, but actually never released - v7 & v8., if we compare to v6.1. Real problems never solved. Lot of crucial components just abandoned, like Application Client , lot of efforts spent on highly regulated and localized features like POS, which will never be an industry standard, because of wrong technical solutions chosen (I have been there) and highly regulated environment. Lot of efforts spent on making Odoo a web portal directly serving websites, none cares for the security concerns, etc. Too little spent on fixing things like floating point accuracy, accounting &, stock performance. Virtually creating a product for tiny enterprises cloud hosting. I see no stance of OCA, in these questions, at all. So what is then a point of passing Aeroo to OCA, just to continue maintaining my own project? It saves the day to someone out there, not for me. Maintenance costs are contributing to TCO, if someone has too high costs of maintaining Aeroo Reports, why then no company contacts Alistek for maintenance contract? So I guess all that are just speculations. I am very interested in answers to these questions, because they are essential, if somebody from OCA could answer, I will move Aeroo under OCA. |
Might be so, that is another point. Because you can not contact anybody if there's even no credit who's who for the project. @pedrobaeza If it's just better collaboration, Github is great tool for it. |
|
Anyway there's another reporting tool on the block. https://twitter.com/RohanNayani/status/512542049900318720/photo/1 |
|
On 09/18/2014 03:50 PM, sraps wrote:
Your name and URL would obviously remain in the author and website |
|
@sraps You can continue making philosophy about the open source ecosystem in general and Odoo one in particular, but this is a real question between developers and integrators, not for final users. I want this tool to be the best - technically and functionally speaking -, and I will collaborate for it, but not for your personal interest in monetizing this. Your credits will be still there, of course, for any customer (mine or from other) to contact you for what they want, and I also thank you to have created this tool, but don't try to retain the project in your hands for this purpose. You don't have any tool to automate and assure code quality, and your criteria to merge a contribution can be arbitrary, which it's not under OCA umbrella. My partner Ana Juaristi (who worked with me in OdooMRP project) has contributed already in the name of both for your still partial migration to v8, so it's not a question of getting things free. If you continue thinking in that closed way, on the "distribution channel" and on version progress, maybe you will not be the right person for the migration to v9 or v10, and someone arises to this figure and OCA (or someone else) want to fund that migration. Regards. |
|
Feel free to publish and promote what and how you want. If it means not having Aeroo in the OCA then that is our loss, but it is your work. I don't see the problem myself. Being active in the community has given us a lot of promotion in itself even if the modules do not carry the Therp logo. |
[9.0] report_xlsx - Improvements, fixes
Added handling of monetary fields
…ADME [10.0] Improve README.rst for report_py3o* modules
* [IMP] is_materialized field non readonly on sql_valid state ; [FIX] block possibility to set indexes on non materialized view * [FIX] set domain_force, group_ids readonly if state > sql_valid * [IMP] better display of the field group_ids * [IMP] possibility to reorder menu items from sql views * [IMP] Do not warn user when setting sql view to draft if state is sql_valid * [REF] * [FIX] Set Date of the first execution in the action name
* [IMP] is_materialized field non readonly on sql_valid state ; [FIX] block possibility to set indexes on non materialized view * [FIX] set domain_force, group_ids readonly if state > sql_valid * [IMP] better display of the field group_ids * [IMP] possibility to reorder menu items from sql views * [IMP] Do not warn user when setting sql view to draft if state is sql_valid * [REF] * [FIX] Set Date of the first execution in the action name
* [IMP] is_materialized field non readonly on sql_valid state ; [FIX] block possibility to set indexes on non materialized view * [FIX] set domain_force, group_ids readonly if state > sql_valid * [IMP] better display of the field group_ids * [IMP] possibility to reorder menu items from sql views * [IMP] Do not warn user when setting sql view to draft if state is sql_valid * [REF] * [FIX] Set Date of the first execution in the action name
* [IMP] is_materialized field non readonly on sql_valid state ; [FIX] block possibility to set indexes on non materialized view * [FIX] set domain_force, group_ids readonly if state > sql_valid * [IMP] better display of the field group_ids * [IMP] possibility to reorder menu items from sql views * [IMP] Do not warn user when setting sql view to draft if state is sql_valid * [REF] * [FIX] Set Date of the first execution in the action name
* [IMP] is_materialized field non readonly on sql_valid state ; [FIX] block possibility to set indexes on non materialized view * [FIX] set domain_force, group_ids readonly if state > sql_valid * [IMP] better display of the field group_ids * [IMP] possibility to reorder menu items from sql views * [IMP] Do not warn user when setting sql view to draft if state is sql_valid * [REF] * [FIX] Set Date of the first execution in the action name
* [IMP] is_materialized field non readonly on sql_valid state ; [FIX] block possibility to set indexes on non materialized view * [FIX] set domain_force, group_ids readonly if state > sql_valid * [IMP] better display of the field group_ids * [IMP] possibility to reorder menu items from sql views * [IMP] Do not warn user when setting sql view to draft if state is sql_valid * [REF] * [FIX] Set Date of the first execution in the action name
Actualizacion rama 11
* [IMP] is_materialized field non readonly on sql_valid state ; [FIX] block possibility to set indexes on non materialized view * [FIX] set domain_force, group_ids readonly if state > sql_valid * [IMP] better display of the field group_ids * [IMP] possibility to reorder menu items from sql views * [IMP] Do not warn user when setting sql view to draft if state is sql_valid * [REF] * [FIX] Set Date of the first execution in the action name
* [IMP] is_materialized field non readonly on sql_valid state ; [FIX] block possibility to set indexes on non materialized view * [FIX] set domain_force, group_ids readonly if state > sql_valid * [IMP] better display of the field group_ids * [IMP] possibility to reorder menu items from sql views * [IMP] Do not warn user when setting sql view to draft if state is sql_valid * [REF] * [FIX] Set Date of the first execution in the action name
[14.0][MIG] report_xlsx_helper_demo
* [IMP] is_materialized field non readonly on sql_valid state ; [FIX] block possibility to set indexes on non materialized view * [FIX] set domain_force, group_ids readonly if state > sql_valid * [IMP] better display of the field group_ids * [IMP] possibility to reorder menu items from sql views * [IMP] Do not warn user when setting sql view to draft if state is sql_valid * [REF] * [FIX] Set Date of the first execution in the action name
* [IMP] is_materialized field non readonly on sql_valid state ; [FIX] block possibility to set indexes on non materialized view * [FIX] set domain_force, group_ids readonly if state > sql_valid * [IMP] better display of the field group_ids * [IMP] possibility to reorder menu items from sql views * [IMP] Do not warn user when setting sql view to draft if state is sql_valid * [REF] * [FIX] Set Date of the first execution in the action name
* [IMP] is_materialized field non readonly on sql_valid state ; [FIX] block possibility to set indexes on non materialized view * [FIX] set domain_force, group_ids readonly if state > sql_valid * [IMP] better display of the field group_ids * [IMP] possibility to reorder menu items from sql views * [IMP] Do not warn user when setting sql view to draft if state is sql_valid * [REF] * [FIX] Set Date of the first execution in the action name
* [IMP] is_materialized field non readonly on sql_valid state ; [FIX] block possibility to set indexes on non materialized view * [FIX] set domain_force, group_ids readonly if state > sql_valid * [IMP] better display of the field group_ids * [IMP] possibility to reorder menu items from sql views * [IMP] Do not warn user when setting sql view to draft if state is sql_valid * [REF] * [FIX] Set Date of the first execution in the action name
* [IMP] is_materialized field non readonly on sql_valid state ; [FIX] block possibility to set indexes on non materialized view * [FIX] set domain_force, group_ids readonly if state > sql_valid * [IMP] better display of the field group_ids * [IMP] possibility to reorder menu items from sql views * [IMP] Do not warn user when setting sql view to draft if state is sql_valid * [REF] * [FIX] Set Date of the first execution in the action name
* [IMP] is_materialized field non readonly on sql_valid state ; [FIX] block possibility to set indexes on non materialized view * [FIX] set domain_force, group_ids readonly if state > sql_valid * [IMP] better display of the field group_ids * [IMP] possibility to reorder menu items from sql views * [IMP] Do not warn user when setting sql view to draft if state is sql_valid * [REF] * [FIX] Set Date of the first execution in the action name
* [IMP] is_materialized field non readonly on sql_valid state ; [FIX] block possibility to set indexes on non materialized view * [FIX] set domain_force, group_ids readonly if state > sql_valid * [IMP] better display of the field group_ids * [IMP] possibility to reorder menu items from sql views * [IMP] Do not warn user when setting sql view to draft if state is sql_valid * [REF] * [FIX] Set Date of the first execution in the action name
* [IMP] is_materialized field non readonly on sql_valid state ; [FIX] block possibility to set indexes on non materialized view * [FIX] set domain_force, group_ids readonly if state > sql_valid * [IMP] better display of the field group_ids * [IMP] possibility to reorder menu items from sql views * [IMP] Do not warn user when setting sql view to draft if state is sql_valid * [REF] * [FIX] Set Date of the first execution in the action name
Following up the discussions at OCA/hr#17 (comment) and odoo ML, I open this issue to decide whether to include aeroo modules under the OCA umbrella, or to move modules like hr_payroll_register_report outside of the OCA.
The text was updated successfully, but these errors were encountered: