openerp-community-leaders team mailing list archive

[Jan Verlaan - Veritos <jverlaan@xxxxxxxxxx>]

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.

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
>