From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757581Ab3KMAGn (ORCPT ); Tue, 12 Nov 2013 19:06:43 -0500 Received: from mail-ea0-f178.google.com ([209.85.215.178]:59274 "EHLO mail-ea0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757035Ab3KMAGh (ORCPT ); Tue, 12 Nov 2013 19:06:37 -0500 Date: Wed, 13 Nov 2013 01:06:33 +0100 From: Ingo Molnar To: Felipe Contreras Cc: "Theodore Ts'o" , Linux Kernel Mailing List , Ingo Molnar , Linus Torvalds , Andrew Morton Subject: Re: [PATCH 2/3] panic: improve panic_timeout calculation Message-ID: <20131113000633.GB2420@gmail.com> References: <1383871600-3831-3-git-send-email-felipe.contreras@gmail.com> <20131111113218.GF15810@gmail.com> <20131111124953.GA6765@gmail.com> <20131111132812.GB7258@gmail.com> <20131111135216.GB8781@gmail.com> <20131111153206.GA22113@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Felipe Contreras wrote: > On Mon, Nov 11, 2013 at 9:32 AM, Theodore Ts'o wrote: > > On Mon, Nov 11, 2013 at 02:52:16PM +0100, Ingo Molnar wrote: > >> > That's exactly what I did. Addressing feedback constructively doesn't > >> > mean do exactly what you say without arguing. > >> > >> Your reply to my routine feedback was obtuse, argumentative and needlessly > >> confrontative - that's not 'constructive'. > > > > Felipe, remember when on the Git list Junio said he would stop trying > > to respond to any patches that had problems because you couldn't > > respond constructively to feedback, and you claimed that you had no > > problems working with other folks, including on the Linux Kernel > > mailing list? > > Ingo Molnar != kernel folks, and I don't see any hints of kernel folks > suggesting to drop patch #1 because of non-technical issues. > > If the patch is technically correct, conforms to standard practices, and > solves a problem; it gets applied. Isn't that how it works in Linux? I simply described to you what is standing Linux kernel maintenance policy. It is not new nor unusual that kernel patch changelog quality matters: defective changelogs are routinely pointed out during review and are required to be fixed before a patch can progress. Linux kernel maintainers frequently push back against deficient changelogs - in fact they are expected to push back against them. Your claim that a changelog defect that got pointed out during review is a 'non-technical', 'administrative' problem in Linux kernel development is simply wrong and your continued stubborn refusal to address such review feedback constructively is unnecessarily complicating the efficient processing of these patches. Thanks, Ingo