openerp-community team mailing list archive

[Graeme Gellatly <gdgellatly@xxxxxxxxx>]

Hi Pedro,

Don't get me wrong.  I do understand, and what follows I am just as guilty
of.  My frustration is not really with this merge proposal, or even my own
ones, but the whole process in general.  It definitely isn't with you.  A
few beers didn't help.  It takes way too long and I see great work
languishing in to's and fro's which are about approach and features until
the original proposer either succumbs or gives up.  It somewhat stifles
innovation and I see the 180 day old merge proposals and think what a
waste.  I see reviewers spending their time on merge proposals which the
original proposer doesn't respond to.

There are major issues with the process that I see as one guy outside the
inner circle.
Root Cause 1.  Not enough reviewers - so while the process looks sound,
unless you are one of the chosen ones, by the time even the simplest merge
proposal is considered, it will conflict on merge, which is just a pain and
rework.  e.g. my simple patch for banking-addons you reviewed which
miraculously got the two approvals, only now to be sitting in needs fixing
even after being rebased.  I have 4 other MP's waiting on that one, I know
you have some more to go in there as well.

Root Cause 2. The reviewer is interested in the module and wants to improve
it (and I am very guilty of this, and my merge propsals attract the same).
Which becomes a bit of cart before horse.  Take this one, I did the
analysis, design and wrote the code in 2010, refreshed it for 7 and
stripped out everything which wasn't core to what it needed to deliver.
One reviewer (you) wants more features.  Another believes it is the wrong
approach and we should have no context in products.  Which leads to more
delays, rework and wasted time.

So perhaps we need a better process whereby rather than re-doing design
after code, and arguing about suitability of functionality, we do design
then code.  Something like.

Create Blueprint or bug report in appropriate area - even if the code is
already cut.
This is the place to determine features, priority, approach, difficulty,
rationale for inclusion and approval that successful delivery will be
merged.
Then judge the proposal against the blueprint/bug.

If new features are wanted (e.g. a kanban view) that are inspired by the
merge proposal, that is great.  Then note it in the merge proposal and
create a blueprint for just that new feature, where it can be discussed
without delaying the merge if it is up to code quality standards,
especially when they are just nice-to-haves.

I will tell you why I think this is good.

Community - not code - drives direction of addons.
If a blueprint is not agreed, then no time is wasted with the
writing/porting/branching overhead.
A bunch of useful afterthoughts are captured as new blueprints, without
delaying merges as different opinions about whether something should be
included or not are discussed.
Generally these will be simpler, or at least better specified providing a
rich source for lesser experienced developers to get involved or more
experienced developers to pick up as a collection when porting or enhancing
the module or branch.
With everything agreed up front the reviewers job becomes much more
straightforward, Does it do what its meant to, sensibly and to standard?
We separate this confusion of guessing design intentions, against what is
right for the branch.  For me the, right now, reviewing and merging is
tough, because what is good and what is right are decided in tandem by the
reviewer after the code is cut.


On Tue, Feb 11, 2014 at 4:53 AM, Pedro Manuel Baeza
<pedro.baeza@xxxxxxxxx>wrote:

> Hi, Graeme, I think you are misunderstanding two concepts of community/OCA:
>
> - OCB, where any backport must remain untouched from original fix proposed
> by OpenERP if possible.
> - Community repositories for addons, where we want to get the best addons
> functionally and technically speaking for using as a common base.
>
> This MP stands in the second case, and suggestions we are doing is to
> improve more the excellent functionality you bring here. If this can't be
> impossible technically, or because you don't have time to work on it, you
> only have to say it, and maybe anyone can make it.
>
> About Markus comments, I'm not agree with them, because I think your
> approach is very good, but this is the place where we can discuss this, and
> I think this enriches even more contributions and our own knowledge (I have
> learned a lot since I started contributing).
>
> Regards.
> --
>
> https://code.launchpad.net/~gdgellatly/openerp-product-attributes/partner-pricelist-7/+merge/202985
> You are the owner of
> lp:~gdgellatly/openerp-product-attributes/partner-pricelist-7.
>

-- 
https://code.launchpad.net/~gdgellatly/openerp-product-attributes/partner-pricelist-7/+merge/202985
Your team OpenERP Community is subscribed to branch lp:openerp-product-attributes.