[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Code reviews

From: Óscar Fuentes
Subject: Re: Code reviews
Date: Tue, 08 Mar 2016 05:15:38 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> Introduce code reviews.  Don't give commit access to the "golden"
>> branches to everyone, just to a few top contributors and reviewers.
> We already have a fair bit of patches submitted and lingering in limbo
> forever until someone (almost always the same someone, BTW) finally
> loses hope that some of the other contributors take care of it.
> If we could switch to a system where every patch is reviewed before
> commit, that'd be great.  My own impression is that it will kill the
> development pace because too few people are willing to spend the
> corresponding efforts.
> That's why I've followed a practice of giving out write access very
> liberally, with "post-commit spot-check reviews" instead.  Indeed, it
> means that errors in commit messages can't be fixed (we can fix them in
> the ChangeLog files, admittedly, but since I don't use them it doesn't
> help me).
> Maybe we could have a half-way system, where commits are pushed to
> a branch that is "not fast-forward-only",

Something like this is what I meant with "Don't give commit access to
the golden branches to everyone". Anyways, you can't expect having high
quality commit logs (or VC history at all, take a look at the DAG to see
what I mean) and give write access liberally. Having ChangeLogs as a
compromise is absurd: you have to proof-read and fix them anyway.
Correct or reject the real thing (the commit) instead.

I guess that asking for a review queue is out of the question, although
I'm afraid that it would not turn to be a good thing since some people
here tend to be quite picky when reviewing foreign contributions (with
the best of the intentions, but I can attest from personal experience
that being the subject of one of those reviews can be disheartening.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]