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. About to create another branch: - Another branch is going to throw a mess in which bug is fixed and which isn't. - Launchpad function to link a bug to a branch isn't very easy/clear to use. - Every bug report is going be filled twice ? One the main stable, and another for the community stable branch ? The main problem is slow merging into 'main' branches of community provided fix. 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 by people that has good karma in code of OpenERP. Means that they are quiet reactive to community, and they know how it works and know if a patch can add a regression or not. Nicolas DS Albert Cervera i Areny a écrit : > 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_include modules are worth as externals, not sure, mrp should depend on >> hr just because of a single field...), so I mean, in Mars 2010 when Tiny >> will say 5.2 get frozen and it's really different from our collective >> partner/experts 5.2, what do we do? This is my only concern because it is >> the path to a fork and I doubt a fork other than Tryton is a good thing, I >> have no reason to believe some leader will drive it better than Tiny >> overall, ERP is not like a CMS or a framework, almost nobody can carry >> such a project alone... Indeed, once we deployed a lot of those parallel >> versions on our customer projects and they will do the work, who will >> afford getting back to an official broken version? >> > > Well, my idea was to only handle this for stable version... what do others > think about this? > > >> I mean I'm hot for that kind of collective/expert work but only if we have >> some guaranties with Tiny this is not a dead end. >> >> Raphaël Valyi >> http://www.akretion.com >> >> >> 2010/1/20 Albert Cervera i Areny <alb...@nan-tic.com> >> >> >>> 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 regressions that are getting in. (The rounding stuff is not a >>> matter of a regression introduced by a programming error. Either OpenERP >>> can't >>> handle some cases the patch is trying to solve or somebody with commit >>> permissions does not know how that works!) >>> - I think most or all patches should have to be discussed in the list. I >>> know >>> it's a lot of work, but it could possibly be worth. >>> - It opens the door to those that don't want to/can't have their own >>> branch (like ourselves) to share resources. >>> - It may reduce the number of resources that those that do have their own >>> branch need to keep it up to date. >>> - If we do the work well, tiny can pretty much relay, review and merge >>> patches >>> from a single branch (not 10s). >>> - They won't receive so much pressure because we currently have our own >>> branch. Tiny can release at their own pace. >>> >>> We all have our own points of view, but there are lots of open source >>> communities out there doing it. We won't always agree but I think we can >>> try >>> it. If meanwhile Tiny solves it's issues and can work as they intend, >>> that's >>> just perfect. If they don't succeed, we won't have lost two months more >>> waiting for them to put a solution on this. I don't think we can put all >>> the >>> responsability to them. >>> >>> Of course, there's nothing that ensures this will work. But note that >>> current >>> approach doesn't work either. >>> >>> BTW, about the marketing stuff, I don't think having a strong community >>> can be >>> bad in any sense. If this approach works it will result in better code >>> and functionality which is the best marketing there is... >>> >>> Just my 2 cents.. >>> >>> >>>> Raphaël Valyi >>>> http://www.akretion.com >>>> >>>> >>>> >>>> >>>> 2010/1/20 Albert Cervera i Areny <alb...@nan-tic.com> >>>> >>>> >>>>> 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 >>>>>> agreed that we need some scheduled released at least (like one per >>>>>> month or per >>>>>> >>>>> 2 >>>>> >>>>> >>>>>> months, this is up to you but I personnaly prefer one per months to >>>>>> make users benefit the more possible bugfix), so why is that not >>>>>> >>> done? >>> >>> >>>>>> Can't >>>>>> >>>>> you >>>>> >>>>> >>>>>> do it? We community have no admin rights neither authority to do >>>>>> the schedule nor the releases. >>>>>> >>>>> 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). >>>>> >>>>> -- >>>>> Albert Cervera i Areny >>>>> http://www.NaN-tic.com >>>>> Mòbil: +34 669 40 40 18 >>>>> >>> -- >>> Albert Cervera i Areny >>> http://www.NaN-tic.com >>> Mòbil: +34 669 40 40 18 >>> > > >
_______________________________________________ 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
