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 each co-worker is up >>> to. Work-sessions and more communication would improve on that. >>> >>> I would not propose a specific community scheme, because I consider >>> unfair that we "hijack" some "official" branch off Tiny. Instead, we >>> should focus on making life easy for Tiny (and the rest of us), with well >>> documented branches and easy-to-merge patchsets. >>> >>> One issue, yes, is releases. That is a Tiny's responsibility (since we >>> could not have arbitrary version numbers in our branches), and we need >>> some kind of agreement that releases won't delay. Even if we end up >>> releasing twice a day, minor versions should be issued immediately when a >>> flaw has been fixed and tested (ie. not wait for a bunch of updates, not >>> try to push irrelevant fixes or features along with a bugfix). >>> >>> Again, I remind you of my suggestion for a *true* distributed source >>> control, which also helps merging and tracking individual patches with a >>> minimal burden. It's more than a year I have been demonstrating that. >>> >>> >>> _______________________________________________ >>> 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 >> > > > -- > 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 -- Joël Grand-Guillaume OpenERP Consultant Business Solutions Camptocamp SA PSE A, CH-1015 Lausanne www.camptocamp.com Phone: +41 21 619 10 28 Office: +41 21 619 10 10 Fax: +41 21 619 10 00 Email: joel.grandguilla...@camptocamp.com http://www.camptocamp.com/fr/business-solutions/formations
_______________________________________________ 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
