OpenZFS branch tracking policy

[Warner Losh]

On Fri, Apr 16, 2021 at 1:24 PM Martin Matuska <mm at freebsd.org> wrote:

> Thank you guys for your input.
>
> OpenZFS 2.1 has already gone -RC3, eliminating even more diffs the code in
> our tree.
>
> I have merged OpenZFS-2.1 RC1 the old way up to the last common commit. I
> don't know who or what body is in charge to make a decision on this matter
> but I would be very happy if a decision is made. I am personally slightly
> in favor of merging directly from OpenZFS as it makes my work easier and
> less prone to mistakes but I don't object doing it the "old" way. But even
> the "old" way is going to be different, as it would mean doing vendor
> merges into stable/13 what we are not used to. On the other hand I do
> "squashed" imports anyway so I could cherry-pick from the new vendor branch
> into stable/13 as well.
>
> One way or another, I would like to continue pushing recent OpenZFS code
> to our tree.
>
Hi Martin,

I think ultimately it is this group, and since I've been handling it, it's
on me to make sure the problem gets to resolution soon. I have one open
issue: if you were to bring in the current OpenZFS branch as  a vendor
branch, would our automation generate a lot of email. I think it would, and
need to make sure it wouldn't, or we'd have some way to limit it before
moving ahead. I hope to know by Tuesday one way or the other....

Warner



> Martin
> On 13. 4. 2021 18:39, Warner Losh wrote:
>
>
>
> On Tue, Apr 13, 2021 at 8:37 AM Ulrich Spörlein <uqs at freebsd.org> wrote:
>
>> Hmm, I don't have an opinion on that one really. Cherry-pick of course
>> only works on a single commit and will not record an additional parent,
>> while a merge commit will have (at least) 2 parents.
>>
>
> Correct.
>
>
>> Some vendor branches sometimes have several commits in between a merge
>> into head, so `git merge` is the natural extension of that. So only some
>> folks can use cherry-pick and, as I said, I'm not sure what the
>> recording of 2 parents gives us ...
>>
>
> So for normal, low velocity updates, there's little benefit from doing
> more than what we've done with vendor imports.
>
> But for OpenZFS I think there's three primary values from store their
> branches in our tree and doing merge commits:
>
> (1) git blame works
> (2) it's possible to bisect down to the exact commit
> (3) Having the merge commits recorded as merge commits makes future
> commits easier (just like vendor branches).
>
> For most things, I agree with Uli: we should have some flavor of 'squash'
> commit that's not really a merge commit to do this.  But for OpenZFS, I
> think there's enough synergy between the two project that having their
> branches in our tree would be a net win for both groups.
>
> Warner
>
>
>> People with more vendor experience should chime in ...
>>
>> Cheers
>> Uli
>>
>> On Mon, 2021-04-12 at 13:08:59 +0200, Martin Matuska wrote:
>> >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
>>
>