From owner-freebsd-git@freebsd.org Mon Apr 12 11:09:08 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 AE77C5CB663 for ; Mon, 12 Apr 2021 11:09:08 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:191:9029::4]) by mx1.freebsd.org (Postfix) with ESMTP id 4FJmFw2Rh2z3rJ7; Mon, 12 Apr 2021 11:09:07 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id 48F7C206838; Mon, 12 Apr 2021 13:09:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by mail.vx.sk (amavisd-new, unix socket) with LMTP id hP49P4Jfafxp; Mon, 12 Apr 2021 13:09:00 +0200 (CEST) Received: from [10.9.8.122] (188-167-101-78.dynamic.chello.sk [188.167.101.78]) by mail.vx.sk (Postfix) with ESMTPSA id AECEB206943; Mon, 12 Apr 2021 13:08:59 +0200 (CEST) Subject: Re: OpenZFS branch tracking policy To: =?UTF-8?Q?Ulrich_Sp=c3=b6rlein?= Cc: Warner Losh , Mateusz Guzik , Ryan Moeller , Alexander Motin , freebsd-git References: <21c7313e-315c-ec48-9437-e0a3d4ec14d2@FreeBSD.org> <41924e9d-9d61-6646-6c8f-e4458f94296e@FreeBSD.org> <30f529c1-6087-e704-8cc7-0c48a40b7430@FreeBSD.org> <9679ec9d-4916-92b7-ff70-0050d699875c@FreeBSD.org> From: Martin Matuska Message-ID: Date: Mon, 12 Apr 2021 13:08:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4FJmFw2Rh2z3rJ7 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] 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, 12 Apr 2021 11:09:08 -0000 If we keep the "old way" than I have an additional question: Wouldn't a "git cherry-pick -Xsubtree=3Dsys/contrib/openzfs" from the=20 vendor branch be a better way to go than "git merge=20 -Xsubtree=3Dsys/contrib/openzfs"? Especially for stable/13, where I have=20 to "merge" in the whole new vendor/openzfs/zfs-2.1-release branch. mm On 12. 4. 2021 11:02, Ulrich Sp=C3=B6rlein wrote: > On Sun, 2021-04-11 at 01:03:30 +0200, Martin Matuska wrote: >> Thank you for your comments, Warner. >> >> What I would like to know is the timing - how much time do we need to >> resolve the issues. I can pull in the OpenZFS code up to commit >> 3522f57b6 the "old" way. This is the last commit common to master and >> zfs-2.1-release and can be cherry-picked to stable/13 the "old" way. >> This will keep our code on par with openzfs-2.1-rc1 (rc2 is out now) a= nd >> I can add a 2-week MFC for stable/13 as usual but there are no >> significant changes at all. After that we need to split main and >> stable/13 and ideally move to direct tracking of OpenZFS. >> >> I have added some comments below. > > I think we should continue with the old way of squashing vendor=20 > changes in, for the main reason of bloat and slowdown for our users.=20 > Note that unlike SVN, a regular user who builds world will clone all=20 > of the git repo including all history. We have many more users than we=20 > have developers working on contrib software, so the slight convenience=20 > of a few FreeBSD devs comes at the cost of the majority of our users. := ( > > I understand the confusion of a broken `git blame` and I'm wondering=20 > if it wouldn't be enough for the folks that want this to fetch the=20 > full OpenZFS repo into their FreeBSD repo. Then when the need arises=20 > to `git blame foo/bar.c` they see an "unhelpful" commit that says=20 > "upstream 01234abcdef was merged" upon which you can run `git blame=20 > 01234abcdef -- foo/bar.c` (paths will be different but it all can be=20 > hidden behind some script and git alias). > > Would that ease enough of the developers pain? > > I wish more stuff would move into ports (llvm, lldb) for reasons of=20 > size also. > > Cheers > Uli