From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 4FCCGkA0wmXRIQEAe85BDQ:P1 (envelope-from ) for ; Tue, 06 Feb 2024 14:29:36 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id 4FCCGkA0wmXRIQEAe85BDQ (envelope-from ) for ; Tue, 06 Feb 2024 14:29:36 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=rdklein.fr header.s=zoho header.b=J3eLC86L; dmarc=none; arc=pass ("zohomail.eu:s=zohoarc:i=1"); spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=2; s=key1; d=yhetil.org; t=1707226176; a=rsa-sha256; cv=pass; b=L+cS/nWoNvZ9q2PN+kKfJrC7XhacoBjMRzRyvfN31UGSU3KURE4sI85H9D1DnE7ExG9m9g jZi4b+HFvvLAnZAldPreUAswoMXu0MG+sGnZbiZFta1a8V085gbGzxhuofb5E81NDE9Cku KPjLJmwykPTNrqA8VjRwU5BxhPF2PLGgBRKxX2ehK7eU6RvmK1lfCNsiVGRN3q6t2clUt9 dM7zdFljeWbmCk5ugoa/HjQlAQmiQNyURMkm82pMRfXTwHtDk1NjqUU5WVBjL4S4y4enKd +pWA5s/bP+FKf+bHGlG8voGsp/VXzgIRNp75fuO3yK/E2z7ecPvA0lfHw0/czw== ARC-Authentication-Results: i=2; aspmx1.migadu.com; dkim=pass header.d=rdklein.fr header.s=zoho header.b=J3eLC86L; dmarc=none; arc=pass ("zohomail.eu:s=zohoarc:i=1"); spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1707226176; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=qWnqgV3IzOa9XXUk/uG6XwB5jt0oC82SKrDagTUCB4Y=; b=GNZgtfZH9PrtFQrtL31AmQ8YHJ2FFTn0Tvs5loSw84lAB7PecFJArY/eHOPTNhlCjcaGx4 Nw3wIe4bdCkbtwdcGsD2wC6UytxugX0v2kPc3WVqNztiR1i7Y9XbQ5tyO5PbLMOzjXHth3 B5/ledvwZsIvUvYZIyphpyU5OD2kV+yekp7i+ISqrMqsQQD81BQXiFPe5HzCRNAytB2zSR Sx546B4ZTlWTAwjQQfFY/k8XZqS/wbddG3yp0Z9+DRAri1Bm9w2WaJ+9PVy7HUB5mpIQDd FkLnnAdgeXC2peQeXPeyVM7GL8+fuyWaSVpzJdtEebOu7wKZZzgFs2YnUDq7Sg== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 8C012E518 for ; Tue, 6 Feb 2024 14:29:34 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rXLVf-00005h-B1; Tue, 06 Feb 2024 08:29:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rXLVc-000055-NM; Tue, 06 Feb 2024 08:29:08 -0500 Received: from sender-op-o10.zoho.eu ([136.143.169.10]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rXLVW-000884-E3; Tue, 06 Feb 2024 08:29:07 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1707226133; cv=none; d=zohomail.eu; s=zohoarc; b=FGb3R7dEnWw9BU1iJ5ggTnMkLNuxS+O/KqvU64ZTpSZlmYvhndwmK2HlK3B6AR8DQ5QkaIrTMgvqosYZ4R8gbUzKRGLouFlW1AA/j9N5FhtefeFUJuhJzQ1lMx1MXOHGjnhRwpNP0JH5gnhdBDsA9YfCOvZaSQ/WBdIUsz5PmoI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1707226133; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=qWnqgV3IzOa9XXUk/uG6XwB5jt0oC82SKrDagTUCB4Y=; b=BTuEE9Cas+OvRTp7JkPHV1Aa+t6t7ikCUOw0MKCZmDUO+H0r6yVeUejCl2QBUCf6Q8FMBfJ/F5US3ZgOdlHyx3fcaQTTACNBZxHX+UjhHxYP/RYpCtQgCbfhmj5Bne2NA/M+gyof07EpViJFL7sJssLWhzP9qMzFhfZDrunpGzM= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=rdklein.fr; spf=pass smtp.mailfrom=edou@rdklein.fr; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1707226133; s=zoho; d=rdklein.fr; i=edou@rdklein.fr; h=References:From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:In-reply-to:Message-ID:MIME-Version:Content-Type:Message-Id:Reply-To; bh=qWnqgV3IzOa9XXUk/uG6XwB5jt0oC82SKrDagTUCB4Y=; b=J3eLC86LIxeaViiM0Fmmo4a3WaPmCsfRy4mSNvQyacd7cvy62chNFpbb8b4P8d5I Jg5ifADdpbx3X/YanWwPIBUGcPeSzGzcvHVulvdeBzwQUc4CtVqae02C4m2fCmByv5M 4ICQwh0f5UDyAa+t8uZCR8t0UyAw1OzExy1qU0HZVlsK6hIh73xO6+tcunZzGsaorGZ Fq2NCKHXOCxsfY4LovRXBtW76lFPss9NYiT87Cc2ivZf4B4q0kRzbJYpeBmiEZ2QCih +yv1bvnUlWi98KNDFUMzTObewOYOblKAVycLFQx+TrbNI+lj0aldkOzMh5LnTzflVff SayKyCmolg== Received: from venerable (20.173.185.81.rev.sfr.net [81.185.173.20]) by mx.zoho.eu with SMTPS id 1707226132760220.07917786319183; Tue, 6 Feb 2024 14:28:52 +0100 (CET) References: <10c82db7-6fc6-4fa0-8213-e207fa54db58@futurile.net> User-agent: mu4e 1.8.9; emacs 28.2 From: Edouard Klein To: Steve George Cc: guix-devel@gnu.org, help-guix@gnu.org Subject: Re: Guix Days: Patch flow discussion Date: Tue, 06 Feb 2024 14:27:25 +0100 In-reply-to: <10c82db7-6fc6-4fa0-8213-e207fa54db58@futurile.net> Message-ID: <87il3167se.fsf@rdklein.fr> MIME-Version: 1.0 Content-Type: text/plain X-ZohoMailClient: External Received-SPF: pass client-ip=136.143.169.10; envelope-from=edou@rdklein.fr; helo=sender-op-o10.zoho.eu X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: help-guix-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx10.migadu.com X-Spam-Score: -8.37 X-Migadu-Queue-Id: 8C012E518 X-Migadu-Spam-Score: -8.37 X-TUID: 89Nu7QJRBkYt I, for one, would be willing to review patches, hoping that in turn my patches would be reviewed instead of staying in limbo forever, which is a drag on me submitting more patches. Is there a procedure to follow, or do I just start replying "LGTM" to patch email threads ? Cheers, Edouard. Steve George writes: > Hi, > > Our goal for the discussion: > > How do we double the number of patches that are *reviewed* and > *applied* to Guix in the next six months? > > Patch flow is a pipeline, to change it we could: > > a. Increase the number of committers - more people to do the > work > b. Increase the efficiency of existing committers > c. Open the gates by decreasing the quality expected from patches > > We essentially decided to focus our discussion on (b). We looked at > things that 'hinder' and 'help' patch review: > > > Hinders > ======== > > - All our patch reviewers are volunteers doing it in their spare time. > > - For a volunteer reviewing someone else's work is not very rewarding, most > would prefer to use that precious time to scratch their own itch. > > - Can feel like an Sisyphean task: no matter how many patches someone reviews > there are more, exacerbated by the number of Guix packages. > > - Sense of responsibility: the minute that a reviewer looks at the patch they > are now stuck with it > > - Repetitive and boring: often patches have minor issues, but it's the same > sorts of issues time and time again. > > - Risk of negative social interaction: having to tell someone that their patch > is incorrect, or that their contribution cannot be used is difficult and > draining. Some people felt it was better to say nothing, rather than to > respond to a patch. > > > Helps > ====== > > This led us to the focus on the fact that **reviewing and applying > patches can be different people** > > We looked for ideas to create more reviewers, make reviewing easier and > more fun: > > > - Share in the work > -------------------- > > 1. encourage new reviewers to step forward - making it more known that reviewing > patches helps to get them applied. Anyone can review patches. > > 2. create directed 'how-to' documentation for reviewing and connect it to QA so > that 'new reviewers' know what to do > > 3. create documentation about 'when' and 'how' it's appropriate to send a 'v2' > version of a patch so that the QA system builds and accepts it. Sometimes, > patches rot because non-committers don't want to be seen as 'stealing' someone's > work with a v2 patch - but making the small changes and resubmitting to QA is > what is required. > > 4. Pay someone else to do it. Noted but out of scope. > 5. Remove old packages overhead. Old untouched packages create mental overhead, > and make the task of maintaining the repository in a good state more difficult. > We could remove old 'untouched' packages and ones that no-longer compile. We > have methods to hide and notify. > > > - Make it more fun > ------------------- > > 1. do online sessions around reviews, some sprints or pairing - both social and > a way to spread skills > 2. find ways to recognise and appreciate reviewers - 'reviewer of the month' > 3. make it a game - we could have a 'Guix London' vs 'Guix Paris' leader board > for reviews. Make it a group goal 'can we beat januarys reviews number' > 4. create some graphs / leaderboard so we know how many patches are being > reviewed and we can recognise the contribution > > > - Automate it away > ------------------- > > 1. Chris is continuing to try and automate away the boring work - general > agreement in the group that QA has made a lot of difference. > > 2. general discussion about create a 'guix review' command (Nix has one) which > would download a branch with the appropriate patch and build it locally. This is > for instances where some adjustment is needed or to check a build. While this > can be done today, it's a number of steps and quite involved. > > > Agreed Actions > ============== > > * [Chris]: continuing his work to improve QA automation. Implication was we'll > need some reports / graphs - but these were not discussed in detail. > > * [Futurile]: organise a **patch review online sessions**. To run every 13 days > (so it rotates through the week) - for 3 months to see if it has any traction. > Co-ordinate with maintainers so that patches that are reviewed can be > committed > > > Actions looking for someone - you? > ==================================== > > * Carry forward the 'guix review' command idea > > * Write an RFC and discuss the idea of removing older 'bit-rot' packages > > * write 'how-to' documentation for reviews and when it's socially > acceptable to do a v2 patch. A checklist-like approach. > > > If you were in the discussion and I've misrepresented your point, or forgotten > an important aspect please please reply and correct me. > > Also, if you would like to help on any of the tasks please email back to the > group so we can all co-ordinate. > > Finally, thank-you to everyone who came along and put their shared brain power > to the task - look forward to doing some patch reviews together online in the > coming weeks! > > Thanks, > > Steve/Futurile