Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Apr 2021 13:08:59 +0200
From:      Martin Matuska <mm@FreeBSD.org>
To:        =?UTF-8?Q?Ulrich_Sp=c3=b6rlein?= <uqs@freebsd.org>
Cc:        Warner Losh <imp@bsdimp.com>, Mateusz Guzik <mjg@freebsd.org>, Ryan Moeller <freqlabs@freebsd.org>, Alexander Motin <mav@freebsd.org>, freebsd-git <freebsd-git@freebsd.org>
Subject:   Re: OpenZFS branch tracking policy
Message-ID:  <da88bd06-7e79-3d2c-38ee-84424a3cef1d@FreeBSD.org>
In-Reply-To: <YHQMru4/ay8lINSk@acme.spoerlein.net>
References:  <21c7313e-315c-ec48-9437-e0a3d4ec14d2@FreeBSD.org> <CANCZdfopOxm-HTYkVPHkEweHw-F%2BA9mk3Vv26x4t3MEAVEd2gQ@mail.gmail.com> <CAPyFy2DS=nsE3-JQdqQC797xQhAiBACkuyA%2BcxkcRY0yeB_6=w@mail.gmail.com> <CANCZdfoPm0tfDpBTU8ORy-_Oa-tkiNX0_MeAdJn0T5ZJdQe6MQ@mail.gmail.com> <41924e9d-9d61-6646-6c8f-e4458f94296e@FreeBSD.org> <30f529c1-6087-e704-8cc7-0c48a40b7430@FreeBSD.org> <CANCZdfp3EJ%2BbrNM02Sfzu_Y42VDEADiApFaX0V9bu_jb5NWd4w@mail.gmail.com> <f8d7a7f3-63a2-434f-054c-fadb9131cf82@FreeBSD.org> <CANCZdfoPzNFSp2sW94Ken=u7DstHL_BWFmjV5MBD4cRBo3t_Uw@mail.gmail.com> <9679ec9d-4916-92b7-ff70-0050d699875c@FreeBSD.org> <YHQMru4/ay8lINSk@acme.spoerlein.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?da88bd06-7e79-3d2c-38ee-84424a3cef1d>