From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: GSoC 2016: applications open, deadline = Fri, 19/2 Date: Wed, 24 Feb 2016 05:52:49 -0500 Message-ID: <20160224105249.GC20807@sigill.intra.peff.net> References: <20160212130446.GB10858@sigill.intra.peff.net> <20160222214246.GE15595@sigill.intra.peff.net> <20160222220248.GC18250@sigill.intra.peff.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Junio C Hamano , Duy Nguyen , git , Christian Couder , Johannes Schindelin , Stefan Beller To: Matthieu Moy X-From: git-owner@vger.kernel.org Wed Feb 24 11:53:07 2016 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 1aYX44-0002iH-CP for gcvg-git-2@plane.gmane.org; Wed, 24 Feb 2016 11:53:04 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756393AbcBXKwy (ORCPT ); Wed, 24 Feb 2016 05:52:54 -0500 Received: from cloud.peff.net ([50.56.180.127]:48223 "HELO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1754659AbcBXKww (ORCPT ); Wed, 24 Feb 2016 05:52:52 -0500 Received: (qmail 29269 invoked by uid 102); 24 Feb 2016 10:52:52 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.84) with SMTP; Wed, 24 Feb 2016 05:52:52 -0500 Received: (qmail 7194 invoked by uid 107); 24 Feb 2016 10:53:00 -0000 Received: from sigill.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.7) by peff.net (qpsmtpd/0.84) with SMTP; Wed, 24 Feb 2016 05:53:00 -0500 Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Wed, 24 Feb 2016 05:52:49 -0500 Content-Disposition: inline In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Tue, Feb 23, 2016 at 02:13:34PM +0100, Matthieu Moy wrote: > > So I think a little back and forth is good; almost everybody does > > something a little wrong in their first patch submission. But I'd worry > > about a topic that is going to involve a lot of bikeshedding or subtle > > nuances to finding the correct solution. I certainly think _some_ > > candidates can handle that, but for the ones who cannot, it may > > frustrate all involved. > > Well, starting a microproject and realizing afterwards that it was a > hard one is frustrating. But picking a very easy project and see someone > else do a brillant job on a harder one, and this someone else get > accepted is also frustrating. My "all involved" also included reviewers and list regulars. :) > I don't think this "kill -Wshadow warning" is really too hard. I'd say > it's hard enough to be interesting for students who have a chance to be > selected in the end. Fair enough. If you want to add it, go for it. The worst that can happen is some failed microprojects. -Peff