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 <[email protected]>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. _______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
