Message ID | C8C4DFDA-998F-48AD-93C9-DE16F8080A02@meta.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp253439wrd; Thu, 2 Mar 2023 22:28:31 -0800 (PST) X-Google-Smtp-Source: AK7set+CbQ8kEv3CjdyhLazn0lyEKtq/fNfPIdHVhrzN4VyVDs98ogyn25ZAzHS/t9H3qn+UGCTA X-Received: by 2002:a05:6402:1608:b0:4c6:9132:65 with SMTP id f8-20020a056402160800b004c691320065mr741776edv.20.1677824910837; Thu, 02 Mar 2023 22:28:30 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1677824910; cv=pass; d=google.com; s=arc-20160816; b=ghdDoFUmiH8fqejbhq+LRbqGnu4JueeF3UP/y9Uifq39EAGmp7q+NychAOdmex6Z2q 6IZ1j4EcTNg0pLV2dnh3A5rtBB8BB6qhmlgEUPJxXx32eKk/FOCvNowkt3+79l/9Ikv9 bVR6uLQ5dd6eUbbFQrScLutfZfIlH1Dlf3QVN5XyNuayiNv1Q/HjJpAYQlM5PU0VBRr8 3FugcPnBW5PNVzu3aIVVxkAQwdRTC3at2ZB5wDtFPEwfHG8wtP33I4D1kY/a7hxEbyHY d9MYSo3e+ByAET5Ug2TYQ1B8lZszYBiQNSQ2ER5oUWt2Uf43SUeW4RlFB7DAbKBLlSr2 qSXg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-id:content-language :accept-language:message-id:date:thread-index:thread-topic:subject :cc:to:from:dkim-signature; bh=WzbF+tKK7VH5Jh8sVA8Gm9VPjHt8CtnRx0l5UFNmvkw=; b=E1OJfs1u8D/uKc10AKQvcCxbm2yVkBkE4/CD3p58gY7iv51Y6lnC7ufdhd9RGGl5mF UAIRnVmJMmlb849yyZBOB87ZguwEVxpu+RyEBpGGN9zo5ahTXi2v9l4VETluj4fxjmB4 s6nAf+cPHPFioqyHU16LGhql73e9QlwBGxodJu6pRg84sJH58HiZBsO2P3rlBVRjfT3t 2e1fIAzuqUdXPffPYJHMWRYF2KQ1lKGWaxhN789MqqBlDIFFz05+4skHLcye6hojleo7 MLCYHDCrXHy4qaxRZ54VVibsZEa+Y4N/iAUEDc5JZ3GZkWU3iZlJ6RaEdEXjMmHWz/P9 ddMQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@meta.com header.s=s2048-2021-q4 header.b=Car2loA0; arc=pass (i=1 spf=pass spfdomain=meta.com dkim=pass dkdomain=meta.com dmarc=pass fromdomain=meta.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=meta.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p9-20020a056402074900b004aaa07a9475si576610edy.50.2023.03.02.22.28.08; Thu, 02 Mar 2023 22:28:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-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=@meta.com header.s=s2048-2021-q4 header.b=Car2loA0; arc=pass (i=1 spf=pass spfdomain=meta.com dkim=pass dkdomain=meta.com dmarc=pass fromdomain=meta.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=meta.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229552AbjCCGXt (ORCPT <rfc822;davidbtadokoro@gmail.com> + 99 others); Fri, 3 Mar 2023 01:23:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229447AbjCCGXq (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 3 Mar 2023 01:23:46 -0500 Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8AA5512587 for <linux-kernel@vger.kernel.org>; Thu, 2 Mar 2023 22:23:45 -0800 (PST) Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3234Unpa023493 for <linux-kernel@vger.kernel.org>; Thu, 2 Mar 2023 22:23:45 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meta.com; h=from : to : cc : subject : date : message-id : content-type : content-id : mime-version; s=s2048-2021-q4; bh=WzbF+tKK7VH5Jh8sVA8Gm9VPjHt8CtnRx0l5UFNmvkw=; b=Car2loA0l1Q6yo+1GCJBPzU4rI2Q5c2vpipnkSx30MAGBNe1qdYFdw7hggIgI2Uv7VDt CQ7uyLJGC6AM595zO1lG0lnYPzlJI2z9x+SjXX2dTMZ/kNL+VFtzhX+CH3CG/X9jn9v3 roiuqgiXyegO07hA/JQDARkKEpiN0ray7iaJoQGYi1PQLHvL+NbMu2tdPR2apNmaidKT MCCHj4PglOeI3uQ4nqPpHKDcSpexlbqyWwu8EX1UwT9o6ankwUlpgtK7CsEMTerOhq4e jZw70vrvzG5A5/IYjYLQks+xMm/H+rhC6Ezt25fst1m68rv/jg7Poce6AOVP8F0s6eSz xw== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2176.outbound.protection.outlook.com [104.47.55.176]) by mx0a-00082601.pphosted.com (PPS) with ESMTPS id 3p2hrvse75-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <linux-kernel@vger.kernel.org>; Thu, 02 Mar 2023 22:23:45 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MoVnVQVZgtLfGoo/nGRw+U9ySL01S4B9ygAQXzF86ndaGWwKCwv0Pl0pDBs3rMeyxT0S1BWhIVWbWlEwAIl37rvdh8MOZNdBAYnB4OX87OF7D9ftvmZvNEx9LSTwRSKedwB0kR5+TAzhr0F+vx0+bSKSO0Gujc4nPaRvkRp4b8hnGTZPa35IU6uF/jgmCy7sDyDeGLfkrd/B/I6sqzncsf6CCshQKWBT/2TJkfs/oB3KqdVGQF3C7f9TPpQ11uG0e49JmZrpLtDV/AjHH/K1TAuXaCpK+mlG1f8A+3ymz8o8WbBOV/e8vYnzh1ihAftUkhDxNihFIQYAzrrxo/34ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WzbF+tKK7VH5Jh8sVA8Gm9VPjHt8CtnRx0l5UFNmvkw=; b=YrnP1AS24/d96+FxRB2jJXylXS95h8nYxRN9th2fI9AzzG20fZyYZnZLJmU1VmM5KLAEeVNyyVLGPZkLPceKIuOG/G3FWVSke8XfUGDnNUU1zDcpgQnozj6j5BNEejGYiQhs/B0EFpHUaU0RtY5j34jLY9O2D8Ch8PssTOOUH/dcvwt/7bgwFcPIbqhrY7iyExYhFiDnSVtyUV+tRKl1rdAzLr4ukGZFHRxZib6h68oq03EqfvA5v9mAf+vrDWpqKtgibCQ+7SrY6UB9FFNOuHUkEyS6YztsVOsyKvY8UxZL7TNV3Bebb25wEedokfVTuAQ7xxa4LcTEPFkFnWs4GQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=meta.com; dmarc=pass action=none header.from=meta.com; dkim=pass header.d=meta.com; arc=none Received: from BY5PR15MB3667.namprd15.prod.outlook.com (2603:10b6:a03:1f9::18) by PH0PR15MB4216.namprd15.prod.outlook.com (2603:10b6:510::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.20; Fri, 3 Mar 2023 06:23:42 +0000 Received: from BY5PR15MB3667.namprd15.prod.outlook.com ([fe80::4376:73:fdf9:d34a]) by BY5PR15MB3667.namprd15.prod.outlook.com ([fe80::4376:73:fdf9:d34a%6]) with mapi id 15.20.6156.018; Fri, 3 Mar 2023 06:23:41 +0000 From: Nick Terrell <terrelln@meta.com> To: Linus Torvalds <torvalds@linux-foundation.org> CC: Nick Terrell <terrelln@meta.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Nick Terrell <nickrterrell@gmail.com> Subject: [GIT PULL] zstd changes for v6.3-rc1 Thread-Topic: [GIT PULL] zstd changes for v6.3-rc1 Thread-Index: AQHZTZizPPDdAbP3s0il0/S8yASGsA== Date: Fri, 3 Mar 2023 06:23:41 +0000 Message-ID: <C8C4DFDA-998F-48AD-93C9-DE16F8080A02@meta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BY5PR15MB3667:EE_|PH0PR15MB4216:EE_ x-ms-office365-filtering-correlation-id: bd0ccefa-2d40-428b-dfcd-08db1bafd585 x-fb-source: Internal x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3vyPkP6FgAodW/z2Q3UtBRaZkOv+9SZC6sFqa8Nivh0j/8d6SFlZ5MecP9xAb+Q8y72c2QUYEoA4phhP4E4j/NWgVTKWfTbauQEpYknCkDYe8te/vul2mQX+C0m9CjOKSEtHF/7u+0gt6Jnye/7EovQmxJuZn35A13iHrZD86at8iqf9FnK+TJmb0r57IJoYAeNnDuSkuCzJmlm/LaeBKKPzK42hgvT8S57SDmIvvhSPwhtyTCtN/Ju511ZpmNKDvkRN5VIABIPE+GBmMx8ZZg/rtnDdJQbDDwzjUkN1iZXiQ4C7lGRMSMVoTLx+O3/9g6IF6qU0gK8Dw6SHPQnK9d0zkZ7pZXQPXAMt6hKnJ4c6BG7Crb3fBQZyh9jD0dE164gwZxTTEnq4tVXHgWe8dWn3jEFazHeTt+JAvOX2HBP4Bnnc7zNK8oVAhyeaSrQoADykvRX0PLE73qN0p+d1lqxFerOFVzN5IltmI++g8lUnX+SU0EHqpC7uHk1M8AsiQNpr41RyEst4Y2hJMxuGX+Z4OnDG9sqK0UioplX+eq5XV4exLVJI498HJWTpg4zNL4js0c/Fa0JOjFigQippHy2sXNG/CIf0LJeMCZIzFqlThuQMEOYgfa7BsJth1UKZIVYq62NsAQcKgYYQ59FohwFiCiczTUhXCIO4FxE28Z794dLypH3isQylxgAY2VAtvZ05B8b1d9TFkUNqBXxCEXAspfMLb4zJWqdec0g/b3E= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR15MB3667.namprd15.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230025)(4636009)(366004)(396003)(39860400002)(376002)(136003)(346002)(451199018)(5660300002)(6916009)(41300700001)(36756003)(83380400001)(8936002)(2616005)(66556008)(316002)(66446008)(66946007)(2906002)(66476007)(76116006)(8676002)(64756008)(33656002)(4326008)(6486002)(38100700002)(966005)(186003)(6512007)(71200400001)(6506007)(26005)(86362001)(122000001)(478600001)(54906003)(38070700005)(45980500001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: 7usg23+hf6XfY4C9itANn2tMYXnZNDyPFYFaXgu+RZLYK+c/OhwLUQC2/SndTZQjKuhF2/ArfzX2M+UUcjQl3LPmt1O+1qSDgW8qSTV3Cz+L6gRGu8YpDs1mMIvJI4y6TqbkHhnWc6oqz1AVm6ags2tnxTXDyAA3sd8SAyh9i700hMkU17MBWP7TYcZ0c9C9e41J1uPKRr2yQ4/UWNAtaSebYerRygFdjFfpn0lrm092O+ejbqnzqDHJKwTiw0/MIzcpklbyAsXLKfXpmQnKtWipQ89gthSR+RZDNeHklZS7Uoz4Bw5LPYB3ghP9HFJFltXjZL1JffwPCotqqB4G25BuRuZZSQU4Lgd9W9CIorg/FCKU7+6fUTLPr7J/aCSQn7W1s05ReAFuU8e4IBnOoUU3ahwsPZdpRjd8Mv+gERZjr2Lh1RAz9y2j4fsVU4fscYM5vHgNXOviSTmoOwpOOrosoUNbWVVz2FO0zhwKPqpLvzuOXUo6kcNms3KW6fW04Qt7l9O6nrjWHJF6mgF5JuLT8eL+7IwEBxYQ13WtFn23XYa8ILEYbgOBRx8Z3DPc2MSe2LnqLhq/jg/etNLnRzmYD2xKEcsbYIhp486Pjt/xkklyYzrMBB9vBNijGpm754ubeAieif8LQ6sPVPVv1N5PgWLTwnoKUirMCpxocEWElB3gmA1YpbAUdAgaCdXLLGd6SeNj4iJtOKRjQHBw+wX0bfzRqAT642MoNDTC8ZyDZTQPmnWps5IphHC/n0u7M/FvSNkAVw9i3oe1M+OUnJqUYw8r6ELAF7u5V9b/ptIbFH3ramUSt1aXnzFLgvmeXNuDKkl686gI1s88NnSKYjU5YfL+RYRno5/cpRulbKOxXGFS4VQCfC+EXBZGZKyqCuPWO6E/W3RzmMArslYdckacfE8wZH7/b7j7pUmhAg2yqvuCqXqwJxC3YPJkSSRpi1Jmi3vHu/XKFj4P/VZy3nkjyfJMxBBrRG2dGaljvPHtZqCnDDateR5aA3RP8/dy5J3xDyYQQEmfc7GmRuXKUzNy2nbyzPzQbSfI2b4kvPi53FL0LuQwCIExyxG/k5WV+I4QNQPIn9ZQ9B+wdJuBG3NTTeGXqVv9PmJ0/kuiXE1kjmVvgF6DpN4Hi7oYBcFOHh6d22Iuq5+sVcUGIF/mPAzSFoKUIS7bFLR2dSJLEm36EW1wlmx8R6G/obcY2MEKvvsHKNzvz2sj5CAAB1uuMvtTilNwFfucx+KD4pQJLlf84x+jiOtzWOh5NzHNLxet2Z/NTJwEHik2DwFsl+wZYwijfZdGIpcX80/WkRthGI7wXGqWN9B/O+3T/tHOqCUG8xZtV6+SwDH8dH1f8e/HlJ7KrCVUwsIJeN0aZbnFfTj+2BFoHwjSc8mP4htX1n1JTIqKImQL/IJ2zCjVuBtAA4ahkgpc3Z/RVnvkpm66L4yI0WRAb/RUG7f3IEzWqd6YnSrz4fIQCIfP9rxAN9pSjZI27YNGT+/59VhOiGsUpXkUxAFeecuZMQwvQevcqTTv3VdLzeAwFHZiuW4qqrPeVCRGyCGetdgWTYngnLeLU9clUh2HHtUnZ8FLmfldugZd Content-Type: text/plain; charset="us-ascii" Content-ID: <AD0D6A2D10F22D41B092A333F59E369A@namprd15.prod.outlook.com> X-OriginatorOrg: meta.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR15MB3667.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bd0ccefa-2d40-428b-dfcd-08db1bafd585 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2023 06:23:41.8292 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ohPolRAnYsne+rLnsy0Hg8cEd+z0RjHBJ04s1VyKqep1gJ2uyLkIkhMu1qAsyjLPqAoB5ynBaoRHhGif3Oxanw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR15MB4216 X-Proofpoint-ORIG-GUID: E8OXjwgPQm_2G0AZbhAmkzKMNgikuqD_ X-Proofpoint-GUID: E8OXjwgPQm_2G0AZbhAmkzKMNgikuqD_ X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-03-03_01,2023-03-02_02,2023-02-09_01 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759326933517507172?= X-GMAIL-MSGID: =?utf-8?q?1759326933517507172?= |
Series |
[GIT,PULL] zstd changes for v6.3-rc1
|
|
Pull-request
https://github.com/terrelln/linux.git tags/zstd-linus-v6.3Message
Nick Terrell
March 3, 2023, 6:23 a.m. UTC
The following changes since commit c9c3395d5e3dcc6daee66c6908354d47bf98cb0c:
Linux 6.2 (2023-02-19 14:24:22 -0800)
are available in the Git repository at:
https://github.com/terrelln/linux.git tags/zstd-linus-v6.3
for you to fetch changes up to 9844ed7e93967c0eaa27cab2fc80583e38696a0e:
Merge tag 'v6.2' into zstd-linus (2023-03-02 22:15:55 -0800)
----------------------------------------------------------------
Zstd fixes for v6.3
A small number of fixes for zstd-v1.5.2.
I'm not pulling in zstd-v1.5.4 from upstream this release because it
didn't have any time to bake in linux-next, but I'm aiming for the next
update in v6.4.
Signed-off-by: Nick Terrell <terrelln@fb.com>
----------------------------------------------------------------
Enrico Scholz (1):
zstd: fix assert() logic
Kees Cook (1):
lib: zstd: Fix -Wstringop-overflow warning
Nick Terrell (3):
Merge branch 'main' into zstd-linus
lib: zstd: Backport fix for in-place decompression
Merge tag 'v6.2' into zstd-linus
lib/zstd/common/zstd_deps.h | 2 +-
lib/zstd/decompress/huf_decompress.c | 2 +-
lib/zstd/decompress/zstd_decompress.c | 25 ++++++++++++++++++++++---
3 files changed, 24 insertions(+), 5 deletions(-)
Comments
On Thu, Mar 2, 2023 at 10:23 PM Nick Terrell <terrelln@meta.com> wrote: > > Zstd fixes for v6.3 Grr. This tree had five commits in it. Of the five, two were merges. And of those two, ABSOLUTELY NONE had any explanation for them AT ALL. Honestly, I pulled this, and was then *so* fed up with this kind of garbage that I just decided that I'm better off without this all. So this got all undone again, and I'm not pulling this kind of sh*t again. I'm *very* fed up with having to tell people the same thing over and over again. Just stop doing merges if you can't be bothered to do do them right. Linus
> On Mar 3, 2023, at 9:28 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > !-------------------------------------------------------------------| > This Message Is From an External Sender > > |-------------------------------------------------------------------! > > On Thu, Mar 2, 2023 at 10:23 PM Nick Terrell <terrelln@meta.com> wrote: >> >> Zstd fixes for v6.3 > > Grr. > > This tree had five commits in it. > > Of the five, two were merges. > > And of those two, ABSOLUTELY NONE had any explanation for them AT ALL. > > Honestly, I pulled this, and was then *so* fed up with this kind of > garbage that I just decided that I'm better off without this all. > > So this got all undone again, and I'm not pulling this kind of sh*t again. > > I'm *very* fed up with having to tell people the same thing over and over again. > > Just stop doing merges if you can't be bothered to do do them right. I’m sorry, I thought this was standard practice for merging in the mainline branch. I’ve been following this article [0], which recommended not rebasing my public trees, so I merged in the mainline kernel instead. I am a newer maintainer, and either I missed the documentation, or it slipped my mind. I will search for documentation about how to write better merge requests. Meanwhile, what do you want me to do with this tree? If the merges are unacceptable, I can rebase the 3 patches in my tree onto v6.2, and re-send the pull request. Best, Nick Terrell [0] https://lwn.net/Articles/512720/ > Linus
On Fri, Mar 3, 2023 at 9:54 AM Nick Terrell <terrelln@meta.com> wrote: > > I’m sorry, I thought this was standard practice for merging in the mainline branch. Absolutely NOT. I have harped on "DO NOT DO BACK MERGES" for closer to two _decades_ by now. When you do zstd development, you should normally have absolutely *ZERO* reason to merge non-zstd work. > I’ve been following this article [0], which recommended not rebasing my public > trees, so I merged in the mainline kernel instead. Half right. You should not rebase your public trees. But you should not merge mainline either. Exactly what relevance does <N> *thousand* driver updates have to zstd? There are reasons to merge, but they have to be real, explicit, and MENTIONED IN THE MERGE. And no, "update to latest" is simply not a reason. When close to half the commits are pointless merges that have no explanation, I will not pull (if I notice). Linus
> On Mar 3, 2023, at 9:59 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > > On Fri, Mar 3, 2023 at 9:54 AM Nick Terrell <terrelln@meta.com> wrote: >> >> I’m sorry, I thought this was standard practice for merging in the mainline branch. > > Absolutely NOT. > > I have harped on "DO NOT DO BACK MERGES" for closer to two _decades_ by now. > > When you do zstd development, you should normally have absolutely > *ZERO* reason to merge non-zstd work. > >> I’ve been following this article [0], which recommended not rebasing my public >> trees, so I merged in the mainline kernel instead. > > Half right. > > You should not rebase your public trees. > > But you should not merge mainline either. > > Exactly what relevance does <N> *thousand* driver updates have to zstd? > > There are reasons to merge, but they have to be real, explicit, and > MENTIONED IN THE MERGE. > > And no, "update to latest" is simply not a reason. > > When close to half the commits are pointless merges that have no > explanation, I will not pull (if I notice). Thanks for taking the time to explain, I appreciate it, and will not make the same mistake again in the future. What do you prefer I do with my current tree? I guess I can either: - Leave the merges in and keep a stable tree - Fix up my tree and clean up the merges, but break the stable tree Best, Nick Terrell > Linus
On Fri, Mar 3, 2023 at 9:59 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > You should not rebase your public trees. > > But you should not merge mainline either. So lwn has several articles about this, the one I found quickly with google was https://lwn.net/Articles/791284/ and it's worth noting that the rule is "don't rebase" and "don't merge from upstream", but as always, those are rules that then have to be balanced against other rules and concerns. Sometimes rebasing _is_ the right thing to do. Sometimes the public history simply ended up being so full of garbage that the only right thing to do is to just admit that and start again. And sometimes merging from upstream _is_ the right thing to do. Maybe there is something really important that made it upstream that is very relevant. But both situations need to be things that you really think about, and have a reason for. And when you do a merge, that reason should very much go into the merge message. For rebases, there's no "rebase message", so those you basically have to explain at pull time ("this was rebased last week to fix bad problem XYZ"). Linus
On Fri, Mar 3, 2023 at 10:03 AM Nick Terrell <terrelln@meta.com> wrote: > > What do you prefer I do with my current tree? I guess I can either: > - Leave the merges in and keep a stable tree > - Fix up my tree and clean up the merges, but break the stable tree In this case, since I'm not taking it during the merge window anyway, just reset and rebase and basically start a new fixes branch that can get pulled next week after it's been in that form in linux-next. All of the actual real commits (ie the non-merge ones) seem to be fixes, so let's just treat them as such. And for sanity reasons, don't start the branch at a "random commit of the day". Particularly not during the merge window. You want the starting point to be something that doesn't have random issues that we may not even know about yet - simply because you want *your* branch to be as stable as possible, and you should aim to have to worry about issues with zstd, not some random "oops, that particular base had a random bug because of some merge window thing that wasn't found until -rc3". So start the fixes branch at a reasonable stableish point (in this case presumably just 6.2). Of course, the same thing is true of new development branches too, not just fixes branches. It's a bad idea to build a house on quick-sand, and it's a bad idea to start new development on some unstable source base. (One special case of "start development at a stable point" is to simply continue off some old point of your previous development. Then it's stable not because it was some known release, but simply because it's what you used previously and had no issues with). That whole "pick a stable point" thing is worth noting also for the case when you _do_ decide that yes, you do need to rebase or back-merge, and you have a good reason to do so. Don't merge a random commit of the day. Merge a _specific_ commit that you can explain why you picked _that_ point to merge. Of course, things like tagged releases aren't necessarily stable by definition - we find things to fix after release too. But at least they are hopefully "we at least tried to make sure it wasn't a bad point". Linus
> On Mar 3, 2023, at 10:16 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Fri, Mar 3, 2023 at 10:03 AM Nick Terrell <terrelln@meta.com> wrote: >> >> What do you prefer I do with my current tree? I guess I can either: >> - Leave the merges in and keep a stable tree >> - Fix up my tree and clean up the merges, but break the stable tree > > In this case, since I'm not taking it during the merge window anyway, > just reset and rebase and basically start a new fixes branch that can > get pulled next week after it's been in that form in linux-next. I will go ahead and do that. > All of the actual real commits (ie the non-merge ones) seem to be > fixes, so let's just treat them as such. > > And for sanity reasons, don't start the branch at a "random commit of > the day". Particularly not during the merge window. You want the > starting point to be something that doesn't have random issues that we > may not even know about yet - simply because you want *your* branch to > be as stable as possible, and you should aim to have to worry about > issues with zstd, not some random "oops, that particular base had a > random bug because of some merge window thing that wasn't found until > -rc3". > > So start the fixes branch at a reasonable stableish point (in this > case presumably just 6.2). > > Of course, the same thing is true of new development branches too, not > just fixes branches. > > It's a bad idea to build a house on quick-sand, and it's a bad idea to > start new development on some unstable source base. > > (One special case of "start development at a stable point" is to > simply continue off some old point of your previous development. Then > it's stable not because it was some known release, but simply because > it's what you used previously and had no issues with). > > That whole "pick a stable point" thing is worth noting also for the > case when you _do_ decide that yes, you do need to rebase or > back-merge, and you have a good reason to do so. Don't merge a random > commit of the day. Merge a _specific_ commit that you can explain why > you picked _that_ point to merge. > > Of course, things like tagged releases aren't necessarily stable by > definition - we find things to fix after release too. But at least > they are hopefully "we at least tried to make sure it wasn't a bad > point". Thanks for the time you’ve taken helping me. I will also take some more time to better familiarize myself with the maintainer workflow, so I can avoid other mistakes that I don’t know I’m making. Best, Nick Terrell > Linus
On Fri, Mar 03, 2023 at 06:03:50PM +0000, Nick Terrell wrote: > > What do you prefer I do with my current tree? I guess I can either: > - Leave the merges in and keep a stable tree > - Fix up my tree and clean up the merges, but break the stable tree Do you have any downstream trees that depend on your tree? If you don't anyone who might be using your tree as a base for forther work (linux-next doesn't count, since it rewinds every working day). In general, for most "leaf" trees, rewinding your branches is not a big deal. There are some people who worship at the altar of "stable git branches which never be rewound, forever and ever, Amen". But that is really a religious belief, and it's one that I don't subscribe to. Sure, if someone is depending on your git tree then rewinding the branch can cause them problems. But not all subsystem trees are used by others as a basis for further work! There are benefits to rewinding / rebasing patches; sometimes I'll do rewind the ext4 dev branch to add a "Tested-By", or to drop a patch which I had merged, but then later on I discovered that it causes regressions. In that case, I'll drop the patch using git rebase -i since it can make life easier who are doing git bisects. Cheers, - Ted