From owner-svn-ports-head@freebsd.org Fri Jun 26 14:15:14 2020 Return-Path: Delivered-To: svn-ports-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8355A358E2C; Fri, 26 Jun 2020 14:15:14 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49tf6V2sTMz4gDd; Fri, 26 Jun 2020 14:15:14 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 57F7116248; Fri, 26 Jun 2020 14:15:14 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f174.google.com with SMTP id h23so7580887qtr.0; Fri, 26 Jun 2020 07:15:14 -0700 (PDT) X-Gm-Message-State: AOAM530QXAJ8TSXJQ5pp/Zg+q0quptczU8rrk4OfP8mr9fnuP6YipVQh 3s+i6lbLbN/zvYyY+2f1ZV9//hof4OoiBYN3arA= X-Google-Smtp-Source: ABdhPJyRMyShoouLcljc74gps05cX3cTVs/vBpeRrIfxAUsY/KWxYweQuC7kZNsv8bLROM3z8O68Fp58rOWEGRifbuc= X-Received: by 2002:ac8:4b47:: with SMTP id e7mr3069437qts.242.1593180913872; Fri, 26 Jun 2020 07:15:13 -0700 (PDT) MIME-Version: 1.0 References: <202006261034.05QAYaDe038059@repo.freebsd.org> <20200626124105.GA65385@FreeBSD.org> <20200626132841.kytmjwquonpwkrhr@aching.in.mat.cc> <20200626133811.GA60522@FreeBSD.org> <20200626134752.i4ygenf4cc6we6nk@aching.in.mat.cc> <20200626135912.GA82842@FreeBSD.org> In-Reply-To: <20200626135912.GA82842@FreeBSD.org> From: Kyle Evans Date: Fri, 26 Jun 2020 09:15:03 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r540489 - in head/devel/fhist: . files To: Alexey Dokuchaev Cc: Mathieu Arnold , "Fernando Apestegu??a" , ports-committers , svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 14:15:14 -0000 \On Fri, Jun 26, 2020 at 8:59 AM Alexey Dokuchaev wrote: > > On Fri, Jun 26, 2020 at 03:47:52PM +0200, Mathieu Arnold wrote: > > On Fri, Jun 26, 2020 at 01:38:11PM +0000, Alexey Dokuchaev wrote: > > > On Fri, Jun 26, 2020 at 03:28:41PM +0200, Mathieu Arnold wrote: > > > > On Fri, Jun 26, 2020 at 12:41:05PM +0000, Alexey Dokuchaev wrote: > > > > > ... > > > > > Please, "svn revert" patches which forwent no functional changes prior > > > > > to making commit. It just clutters the diff and decreases SNR. :-( > > > > > > > > In that particular case, it was correct to commit the patch, it has > > > > functional change, the range information changed > > > > > > I see only patch header change, and I'm pretty sure the old patch would > > > apply just fine (if by "range information" you mean the line address). > > > > > > Generally, patch(1) does fuzzy application very well, which allows to > > > carry patches unmodified literally forever (until patched file changes > > > enough so the patch no longer applies). > > > > > > If you were talking about something else, please be more specific. > > > > I was talking about the range information, yes, the line numbers. It is > > true that patch(1) does fuzzy patching, and it did when it applied that > > patch. The committer then checked that it was still building correctly, > > More accurately put, checking that fuzzy application DTRT is what needs > to be checked. > With my "have worked on patch(1)" ballcap on, you understand how patch fuzzing works, right? The very *definition* of fuzzing in patch(1) is not doing the right thing, because it's ignoring patch context. In my ideal world, the ports tree would run with -F0 because it's absolutely nonsensical to let it look like it might have done the right thing. No one is going to check that the result is actually correct, just that it compiles. These are not the same thing. Thanks, Kyle Evans