A Divendres, 22 de gener de 2010, Joël Grand-Guillaume va escriure: > 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 !
snip > P.S. May be a community branch is better than 6 "partners" branches if Tiny > won't change something.... This is the question. I think we all agree that main branch should be much more stable and mantained by Tiny with quality processes. Even more, this thread is full of suggestions and good ideas of what Tiny should do. But reality is Tiny doesn't even have the time to answer to a thread that is located in the "leaders" mailing list. I'm not sure if Tiny needs a leader mailing list to tell them what to do, or to improve things as much as they can. If one community branch is really better than 6 partners, maybe that's a start... > > 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
