← Back to team overview

openerp-community-leaders team mailing list archive

Re: Simple things we need from Tiny for better bug planning/management

 

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.




Follow ups

References