1. Mailing Lists
  2. Contributors
  3. Re: Self-merging rule

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: Self-merging rule

Re: Self-merging rule

Avatar

Re: Self-merging rule

by
Matmoz D.O.O., Matjaž Mozetič
- 26/08/2015 06:14:21
Just don't get in the same path where nearly every organization that hires me went, to get in the situation they needed someone like me in the first place. "Merging privileges", "Authorized Approvers", etc. sounds awful like plain old-school bureaucracy.

Don't get me wrong, the supervision/control is needed, but keep in mind: every "privilege" has to be proportional with "duty" (not just responsibility, that one is a must for every single party involved in a process), and I'm not sure if in a community of mostly "pro bono" collaborators we can afford "duty". Duty means: if someone has the privilege to do something, he has also the duty to do that thing in a certain time limit in a certain manner. Privilege without duty leads to where most of public administrations are today - paper pushers (or button pushers in our case), and those are the first one getting fired once we start streamlining a business process, since they're not just useless, but they can be considered anchors slowing or even stopping the flow.

Analyze the current situation: a PR is made and a certain number of reviewers approval is needed. In some repositories the process is quick, in others is slow (or nearly none).

Analyze the projection of the even more restricted flow: a PR is made and a member of a certain group has to approve - the process in most of the repositories will be slow (or nearly stopped).

The current situation is not optimal, but don't correct a problem with an even worse one. If something is wrong in a process, find a way to ease the flow, not to limit it. We're already losing good commits for technicalities (a commiter doesn't know, how to do the CLA, a committer is not used to use git and rebase, ...).



On Tue, Aug 25, 2015 at 9:08 AM, Daniel Reis <dgreis@sapo.pt> wrote:
+1 for not self-merging

I've also been asked to not do it, I've avoided it since then, and think 
it works well.
Merging is a last checkpoint, and should be done by an independent 
manitainer.
There are many people with write access, adding a comment asking for it 
to be merged is not an issue.

--DR

Às 13:22 de 23/08/2015, Pedro Manuel Baeza Romero escreveu:
> Hi all,
>
> I faced some days ago a complaint from Stefan Rijnhart about myself 
> merging one of my PRS when the number of approvals was the appropiate. 
> This is an old OCA rule that was applied on old Launchpad times.
>
> This rule is not even in the current OCA contributing guidelines 
> (https://github.com/OCA/maintainer-tools/blob/master/CONTRIBUTING.md#review), 
> but he insists on bringing this topic to the mailing list.
>
> I see no special reason to apply again this rule nowadays, because 
> thanks to the merge button, the task doesn't involve any special risk 
> to screw up things. In Launchpad, there was this risk, as the merge 
> implies some manual operations that can lead to a bad merging, but as 
> I said, today this is not a problem.
>
> What the others think about this rule?
>
> Regards.
>
> _______________________________________________
> Mailing-List: http://odoo-community.org/groups/oca-contributors-15

_______________________________________________
Mailing-List: http://odoo-community.org/groups/oca-contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe




--
Matjaž Mozetič, CEO

Reference