OpenZFS branch tracking policy

[Ulrich Spörlein]

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