From owner-freebsd-git@freebsd.org Mon Jan 4 19:46:39 2021 Return-Path: Delivered-To: freebsd-git@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 1EE8A4C8580 for ; Mon, 4 Jan 2021 19:46:39 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a05:fc87:1:5::15]) (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 (2048 bits) client-digest SHA256) (Client CN "www.spoerlein.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D8mNG6JcGz3tRY for ; Mon, 4 Jan 2021 19:46:38 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from localhost (acme.spoerlein.net [IPv6:2a05:fc87:1:5:0:0:0:15]) by acme.spoerlein.net (8.16.1/8.15.2) with ESMTPS id 104JkaQ8098334 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 4 Jan 2021 20:46:36 +0100 (CET) (envelope-from uqs@freebsd.org) Date: Mon, 4 Jan 2021 20:46:36 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Mark Millard Cc: Mark Millard via freebsd-git Subject: Re: Reporting context with list submittals for defects when local git branches are involved: needs a new description? Message-ID: References: <89B5ACB3-C05C-40EB-AF0B-5E049928DD6D.ref@yahoo.com> <89B5ACB3-C05C-40EB-AF0B-5E049928DD6D@yahoo.com> <29E9AA04-C66B-4298-B84D-6549A88C038B@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.0.2 (2020-11-20) X-Rspamd-Queue-Id: 4D8mNG6JcGz3tRY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 19:46:39 -0000 On Mon, 2021-01-04 at 09:27:10 -0800, Mark Millard wrote: >On 2021-Jan-4, at 08:28, Ulrich Spörlein wrote: >> >> I'm a bit confused as to what you are asking here, tbh. Are you working on a branch of your own? In that case, a bug report needs to have some concrete pointers to what you've changed locally, or you need to revert to a clean tree or something. > >Old PowerMacs do not work sufficiently based on pure FreeBSD. But my >workarounds are genrally not sufficient for committing either. (powerpc >is the primary context that lead to me having some patches. I'll use it >for illustration.) Many problems have nothing to do with what I've >patched. When I can, I instead report based on instead using >artifact.ci.freebsd.org material and its behavior, but some bugs do not >show up in debug builds or the PowerMac support problems make this not >work. > >In complicated cases that allowed it, I've reported both from using >artifact.ci.freebsd.org material and from using my patched context, >in part demonstrating that a problem exists in both but providing >additional evidence. > >> Or do you just want to have some minor things modified on your tree? > >That would probably be a reasonable view of my patches accumulated over >the years, patches that I bring forward as I go. Adding a new one is >fairly rare. > >> In that case, maybe using git stash and git rebase --autostash would suit you better? > >A possibility, but I'm exploring alternatives. git is likely to lead to >more people having local branches involved in how they choose to operate. >That in turn may lead to more reports based on such contexts. My exploring >may be an early warning. Ah, sorry for being dense earlier. You are correct in pointing out that it might get a bit harder to see from problem reports what exact version a user was running. I feel that typically we ask of users to upgrade to latest current or stable anyway before reporting bugs, so just the information that they are somewhat up to date is usually good enough. But we might have to do something smarter in the future, indeed. Thanks! Uli