Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp2078742rwd; Tue, 13 Jun 2023 19:54:27 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ55CeNgTiBDFsbJJFTKgS34YTAi/u9ro7XmgLPeH9F+O/GLfy4tuvo2a0zZgivADS8b/c6h X-Received: by 2002:aa7:c996:0:b0:514:8fdb:855e with SMTP id c22-20020aa7c996000000b005148fdb855emr7184460edt.22.1686711267335; Tue, 13 Jun 2023 19:54:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686711267; cv=none; d=google.com; s=arc-20160816; b=wjYykHnEJmjZsIZkziSyx4Ce+MJ8SAzi9yLmJ23qvmNMMRAfEEzOx9bPXwAnSdFOsg HEJZyxDMUh5PM+jTi+fcPxm3ulOU2qUlsWx9j7Ibbosfb2xdLKVEIP7UXdh3NTWXj3Km 0kgJwbmkhijxPlCEd0zvQS1ERKGflioISeoMwcYxVzL/veGrIm6ys47kkYXzbb4Ee2uI OD+zTnzL2p1W8Gx0f0bwsz4szOX5cnSSoX/NdLXk9yq7uukQpfILnBnKlpl0UG0fFckq iJ90SgD2FVx/oNm/JWNTIkFGczjgdaWXsuHmeug0R7gpH15L28GvQnTZZALQXMH0qcK5 F+lQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=N3q6ixAinHSWilzVMCv++DW3xSimSHnyP2PRlOaULYE=; b=QHNbh4AnADLRK0G9hBUcTS5DozLSHMNdjw7JFcpIr5YKViwKZyb5pUkHwJ5kYsxOF5 b0X/zIKvinAzrRgK82FQd1f9tDJT5lRxBHfLQ9BHDqeEHcMtdLrWapRpSYL7ZsNhg6w8 vxm5edoSPshcewojkkhCdnikrs9jj1uV+WL7MgLVn9b1zGy4bQVki8Jy8TbacXqqrEti PmuJCynEE8AGn3aTxORy1Vk2aVwXIvpfEOnd3WYWulWEJO09soaxnuEu7GLVN6YYU7k6 bOoRmdEYhbrsSte+jlHOo9bDtfUNNQW/DoC+fxXxzTx1cvNp0RATjWCpxbwVLtvjcXmk EGRg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=aHS8GGlV; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i18-20020a50fc12000000b005188259bbe0si419234edr.369.2023.06.13.19.54.11; Tue, 13 Jun 2023 19:54:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=aHS8GGlV; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242231AbjFNCwB (ORCPT + 61 others); Tue, 13 Jun 2023 22:52:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242165AbjFNCv6 (ORCPT ); Tue, 13 Jun 2023 22:51:58 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 958D92690; Tue, 13 Jun 2023 19:51:38 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 099A962F37; Wed, 14 Jun 2023 02:51:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0878AC433C0; Wed, 14 Jun 2023 02:51:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686711097; bh=N3q6ixAinHSWilzVMCv++DW3xSimSHnyP2PRlOaULYE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=aHS8GGlVpVMza8fUd10dHWgjcsEcnhYF6mtda1PEif73/gG8DJjgjRD496BZG2+IQ yZb0yLikA3pccFbH6043Pq5QZcqOroZdRH/n0aPMe6tt6rd6svMoQlkxrdOQGMmm5p gPTCRZNFuEphlrZWYkI0t495rTPGdcZJ6IzKlD2J5Zsf62F+leEV0MUgVETVEw0vup sMwdFgG4EQYtmZ9JqLK5OUrSJZXnIspVyWrfW0tKAsYBWwuyMLC6UVSY84A9XKx8KM hmEOCqZIbZ55Y5QXW5euBztlUDZTHbx6k9Q1KnD2gow6ubRUlJEXvAxIGp7m80p1TK vqIb4LmfdSHew== Date: Tue, 13 Jun 2023 19:51:36 -0700 From: Jakub Kicinski To: Johannes Berg Cc: Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= , Kalle Valo , linux-wireless@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, regressions@lists.linux.dev Subject: Re: Closing down the wireless trees for a summer break? Message-ID: <20230613195136.6815df9b@kernel.org> In-Reply-To: References: <87y1kncuh4.fsf@kernel.org> <871qifxm9b.fsf@toke.dk> <20230613112834.7df36e95@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Tue, 13 Jun 2023 22:00:35 +0200 Johannes Berg wrote: > On Tue, 2023-06-13 at 11:28 -0700, Jakub Kicinski wrote: > > On Tue, 13 Jun 2023 20:14:40 +0200 Toke H=C3=B8iland-J=C3=B8rgensen wro= te: =20 > > > I think this sounds reasonable, and I applaud the effort to take some > > > time off during the summer :) > > >=20 > > > One question that comes to mind is how would this work for patchwork? > > > Would we keep using the wireless patchwork instance for the patches > > > going to -net in that period, or will there be some other process for > > > this? I realise the setup we have for ath9k is a bit special in this > > > regard with the ack-on-list+delegation, so I'm obviously mostly > > > interested in what to do about that... :) =20 > >=20 > > Whatever's easiest :) It's probably a good idea for Kalle to write > > down all the local rules and customs and share those with us. >=20 > While that's probably a good idea regardless, I'd think that patchwork > doesn't really matter that much - we'll have some catching up to do > anyway after the vacations, so looking through patchwork etc. would be > perfectly acceptable. Worst case we'd notice when a patch doesn't apply, > right? :) Right, I meant it more in terms of patch flow. Is looking at which drivers have a tree specified in MAINTAINERS enough to know what should be applied directly? > Wrt. ath9k patches I guess "delegate in patchwork" won't work anymore, > but "resend to netdev" or something perhaps? We can watch PW state and apply from linux-wireless, I reckon. That said I don't know how you use delegation :)