From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A7C7912B7D for ; Thu, 17 Aug 2023 12:42:51 +0000 (UTC) Received: from pendragon.ideasonboard.com (213-243-189-158.bb.dnainternet.fi [213.243.189.158]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 76080283; Thu, 17 Aug 2023 14:41:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1692276095; bh=nKRYcOY5VHb6IO2hR9J7uLJEU6umPuhamo6O6kwTc7Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iQYCHxtp0TzVKiUXB000trfOzkUmZUEMiFobNb34TmknqmwWlcBepmegjZSwKFT72 HyCpyDhEs1+xzZcC7kcR0qGI99D9N61SMBmcq1bRBHAe7X+8H8q4uv9yssN5PtdfQI SdtCCb2Lvu9QducTdS6FS9aCqjCToBhoFXygl0QU= Date: Thu, 17 Aug 2023 15:42:55 +0300 From: Laurent Pinchart To: Mark Brown Cc: Jani Nikula , Luis Chamberlain , Josef Bacik , ksummit@lists.linux.dev, Jeff Layton , Song Liu Subject: Re: [MAINTAINERS SUMMIT] Maintainer burnout Message-ID: <20230817124255.GI21668@pendragon.ideasonboard.com> References: <20230816180808.GB2919664@perftesting> <87ttsx98ue.fsf@intel.com> Precedence: bulk X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Thu, Aug 17, 2023 at 01:17:39PM +0100, Mark Brown wrote: > On Thu, Aug 17, 2023 at 03:00:57PM +0300, Jani Nikula wrote: > > On Wed, 16 Aug 2023, Luis Chamberlain wrote: > > > > In so far as making it possible to get b) to help, my current excitement > > > surrounds around what Song Liu mentioned to me at LSFMM and then > > > quickly demonstrated that the eBPF folks are doing with patchwork. > > > Get the patches to be tested automatically, and *immediately* > > > patch reviewers and maintainers can get feedback if something is not even > > > worth reviewing. > > > I'm all for automated testing and CI, and all i915 patches get tested > > before merging. But requiring everything to pass before a human so much > > as looks at it can be incredibly demotivating for contributors. For > > example, if they polish the contribution, and take all corner cases into > > consideration to pass the tests... and then get told their design is all > > wrong and needs to be redone from scratch. It's a balance. > > Indeed, and you're relying on your test automation being robust, the > results being available promptly and the results being comprehensible if > people can't readily run the tests themselves. That said I read the > above as more providing results so people can look at them rather than > gating looking at things (eg, if everything is failing it's probably > fine to not bother) - that seems a lot more reasonable. I think the rules will need to be somehow flexible. As Jani mentioned, there's a genuine need to be able to discuss design questions before a patch series reaches perfection (experienced developers will usually know that they should mark their series as RFC in that case, but newcomers may not have this tribal knowledge). On the other hand, I'm not going to discuss the design behind a patch series if the code is intended with 3 spaces and uses CamelCase. Reports from automated tests, or automated reviews, should be designed to help the submitter, not to scold and discourage them. I'm pretty sure we can come up with wording that will be nicer to read than what I would write when being tired at 3:00am, repeating the same comment for the 50th time. -- Regards, Laurent Pinchart