voting in gerrit: merge at +3? (+2+1 / +1+1+1)

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Mon Nov 19 06:33:09 UTC 2018


Hi Pau,

On Tue, Nov 13, 2018 at 05:08:49PM +0100, Pau Espin Pedrol wrote:
> I agree with implementing this kind of change, I really like the idea of
> getting more people into reviewing and their vote counting so there's no
> need for somebody with +2 to merge it.

ACK.

> The only drawback I see is the fact that if +3 is needed, then a +2 from
> some people is now not enough, which can be a pity for patches that can be
> merged quickly (cosmetic, logging, etc.) or important fixes which require
> quick merge.

ACK. That's why I think eventually a +3 will be needed.  But I'm happy to
give the current proposal a (short) try.  If we get a backlog of patches
at "+2" stage that don't reach "+3" then we must quickly introduce +3.

> Also, for some repos most people don't care bout or don't have much
> knowledge about it, for instance the case os myself and osmo-gsm-tester,
> where I usually +2 my patches right away or after leaving them under review
> for a few hours/days. This would block my development or fix of
> setup-related issues.

Equally ACK here.  It's frequent practise in some projects that lack a wider
community.

> So good for me, but we need to resolve this kind of details in the proposal
> beforehand.

Indeed, the +3 "privilege" should be configured from day one, with
nobody enjoying it until we see a need for it.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list