OpenZFS branch tracking policy

[Martin Matuska]

If we keep the "old way" than I have an additional question:

Wouldn't a "git cherry-pick -Xsubtree=sys/contrib/openzfs" from the 
vendor branch be a better way to go than "git merge 
-Xsubtree=sys/contrib/openzfs"? Especially for stable/13, where I have 
to "merge" in the whole new vendor/openzfs/zfs-2.1-release branch.

mm

On 12. 4. 2021 11:02, Ulrich Spörlein 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) and
>> 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 
> changes in, for the main reason of bloat and slowdown for our users. 
> Note that unlike SVN, a regular user who builds world will clone all 
> of the git repo including all history. We have many more users than we 
> have developers working on contrib software, so the slight convenience 
> 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 
> if it wouldn't be enough for the folks that want this to fetch the 
> full OpenZFS repo into their FreeBSD repo. Then when the need arises 
> to `git blame foo/bar.c` they see an "unhelpful" commit that says 
> "upstream 01234abcdef was merged" upon which you can run `git blame 
> 01234abcdef -- foo/bar.c` (paths will be different but it all can be 
> 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 
> size also.
>
> Cheers
> Uli