Using Gerrit for code review in KDE

[Kevin Krammer]

On Saturday, 2014-09-13, 20:38:21, Eike Hein wrote:

> These things reinforce each other in multiple ways. If main-
> tainers are not entrenched positions, they're easy to replace
> when they move on (whether they can accept this themselves or
> not). Once you codify them in ACLs (and yes, we do this in
> some places already, and I think this was a mistake as well)
> you add inertia because those ACLs need to be updated, and
> someone needs to work up the gumption to ask for that update.
> 
> (Case study of what can happen when we lose track of this:
> We lost KDM. There are many more positive case studies where
> contributors kept projects alive once maintainers disappeared
> just by slowly ramping up their involvement, without needing
> "hand over the keys" flag days.)

Hmm these are good points.

I guess most people commenting so far have done so from a mostly KDE 
frameworks point of view, where maintainers want to be actively involved 
instead of having to reactively revert changes that don't fit or need more 
discussion.

So your suggestion would be to not have +2 but a policy of some sort that only 
the +1 of the maintainer, if there is an active one, is considered as "go 
ahead"?

> If maintainers aren't entrenched, you also can't rely on them
> picking up the slack; hence encouraging stepping up.
> 
> How do you become a maintainer? By actively doing review,
> for one. I.e. it's up to *maintainers* to stay active and
> involve themselves in the process, and provide guidance so
> that good code goes in and bad code stays out. The safety
> net we have for review working is our brains when making
> or picking through arguments.

That sounds similar to Qt's approvers.

> The argument "but you can still bypass Gerrit and push
> directly, this is just social etiquette" doesn't matter
> because the whole thing is about social etiquette. The
> ACLs we already have reflect our social etiquette, and
> that means we need to be careful and think smart about
> evolving it.
> 
> Personally I think social etiquette encouraging the use
> of review tools is fine. Social etiquette that entrenches
> some developers as special on those review tools is not.

If I brainstorm about alternatives I find:

* let maintainers have -2 as pro-active variation of reverting

* build social ettiquette to always wait for the maintainer's +1 but at most 
for a certain grace period, e.g. one week

* have everyone get +2 and use etiquette to do that only if there is already 
strong agreement or the grace period has passed

Other?

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20140913/b12791d4/attachment.sig>