openerp-community-leaders team mailing list archive

[Sharoon Thomas <sharoonthomas@xxxxxxxxxxxx>]

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.grandguillaume@xxxxxxxxxxxxxx>

> 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@xxxxxxxxxxxxxxxxxxx
>
> 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@xxxxxxxxxxxxxxxxxxx
>
> 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@xxxxxxxxxxxxxxxxxxx
> 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.grandguillaume@xxxxxxxxxxxxxx
> http://www.camptocamp.com/fr/business-solutions/formations
>
>
> _______________________________________________
> 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
>
>