From mboxrd@z Thu Jan 1 00:00:00 1970
From: Thomas Rast
Subject: Re: GSoC 2014: Summary so far, discussion starter: how to improve?
Date: Sat, 26 Oct 2013 10:14:21 +0200
Message-ID: <87txg4qwiq.fsf@linux-k42r.v.cablecom.net>
References: <8761stx04i.fsf@linux-k42r.v.cablecom.net>
Mime-Version: 1.0
Content-Type: text/plain
Cc: git@vger.kernel.org
To: Junio C Hamano
X-From: git-owner@vger.kernel.org Sat Oct 26 10:14:43 2013
Return-path:
Envelope-to: gcvg-git-2@plane.gmane.org
Received: from vger.kernel.org ([209.132.180.67])
by plane.gmane.org with esmtp (Exim 4.69)
(envelope-from )
id 1VZz17-0008LF-5O
for gcvg-git-2@plane.gmane.org; Sat, 26 Oct 2013 10:14:41 +0200
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S1752153Ab3JZIOg (ORCPT );
Sat, 26 Oct 2013 04:14:36 -0400
Received: from psi.thgersdorf.net ([176.9.98.78]:50263 "EHLO mail.psioc.net"
rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
id S1751817Ab3JZIOe (ORCPT );
Sat, 26 Oct 2013 04:14:34 -0400
Received: from localhost (localhost [127.0.0.1])
by localhost.psioc.net (Postfix) with ESMTP id F24CF4D6514;
Sat, 26 Oct 2013 10:14:32 +0200 (CEST)
X-Virus-Scanned: amavisd-new at psioc.net
Received: from mail.psioc.net ([127.0.0.1])
by localhost (mail.psioc.net [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id S1-T9lnKclId; Sat, 26 Oct 2013 10:14:22 +0200 (CEST)
Received: from linux-k42r.v.cablecom.net.thomasrast.ch (unknown [213.55.184.158])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client did not present a certificate)
by mail.psioc.net (Postfix) with ESMTPSA id 4095E4D6414;
Sat, 26 Oct 2013 10:14:22 +0200 (CEST)
In-Reply-To: (Junio C. Hamano's
message of "Tue, 22 Oct 2013 14:31:35 -0700")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)
Sender: git-owner@vger.kernel.org
Precedence: bulk
List-ID:
X-Mailing-List: git@vger.kernel.org
Archived-At:
Junio C Hamano writes:
> Thomas Rast writes:
>
>> Theories
>> ========
>>
>> * Scope creep: projects tend to get blocked on some bigger
>> refactoring/restructuring task that was not in the original
>> proposal.
(Full disclosure: I actually proposed this theory.)
> I think that is a sign that the original proposal did not look
> enough at the existing code, dreaming of a pie-in-the-sky shiny
> features in a green-field setting. What needs to be done within the
> constraint of the existing code (including a total rewrite, if
> necessary, while keeping the project's codebase maintainable is part
> of the healthy develpment.
Hmm, yes, but it's also the only objection that I believe I have never
heard, as opposed to ignored.
I'm okay if we just file this under "things to consider during project
proposal review".
>> * Have students review some patches
>
> I am not sure if this would help.
>
> Reviewing the patches to find style violations and off-by-one errors
> is relatively easy as it can be done with knowledge on a narrow
> isolated part of the system. Reviewing the design to make sure that
> the change fits the way how existing subsystems work, ranging from
> the internal API implementation level to consistency a changed
> behaviour is presented at the UI level, however, needs understanding
> of the far wider entire project than only the parts of the system
> the proposed change updates. It will be even more true if the chosen
> topic is a cool/shiny one.
I'd choose the middle path: review for code readability. What do the
functions do? Are the functions and variables named after their roles?
Is there anything that I cannot understand, and therefore warrants a
comment?
That is much more difficult than just reviewing for style, while it can
(usually) be done without too much knowledge of the outside.
--
Thomas Rast
tr@thomasrast.ch