Re: OpenZFS imports, status update

After some discussion and experiments. Following are the current
status and the planned route:

Currently the staging git repository has been updated:
https://cgit-dev.freebsd.org/src/

See the merge commits in main and stable/13 branches, and now we have
three branches under vendor/openzfs/:

  - vendor/openzfs/master (imported from upstream openzfs/master, will
be merged to main)
  - vendor/openzfs/zfs-2.1-release (imported from upstream
openzfs/zfs-2.1-release, will be merged to stabe/13)
  - vendor/openzfs/legacy (renamed from the old vendor/openzfs)

To Ulrich: the plan is importing openzfs branches as-is (same hash
values) to the vendor/openzfs so the history of the old vendor/openzfs
can not be shared.

We have modified the commit hooks to:

  1. Allow vendor/openzfs/* branches import commits from committer
with address not @FreeBSD.org
  2. Allow merge from vendor/openzfs/zfs-2.1-release to stable/13
  3. The commit mail generated for the vendor branch will be "one mail
per push", not having the complete diff but a list of commits' short
hash and subject line.

And to allow creating master and zfs-2.1-release branches in the
vendor/openzfs namespace, we need to rename the original
vendor/openzfs to create rooms for them. Because we disallow deleting
branches or other destructive operations from remote and it's not that
cost-effective to modify the configuration and hooks for this single
operation. I would like to just rename the branch on the server, with
command:

    git branch -m vendor/openzfs vendor/openzfs/legacy

The people have local branch tracking the original vendor/openzfs will
encounter issues like this whey doing `git pull`:

    error: cannot lock ref
'refs/remotes/freebsd/vendor/openzfs/legacy':
'refs/remotes/freebsd/vendor/openzfs' exists; cannot create
'refs/remotes/freebsd/vendor/openzfs/legacy'

The solution is update the upstream of the tracking branch:

    (change "freebsd" to "origin" if you use default remote name)
    git update-ref -d refs/remotes/freebsd/vendor/openzfs
    git branch -u freebsd/vendor/openzfs/legacy vendor/openzfs/legacy

I will send an announcement for this operation and migration tip to
-git and other related lists.

Please let me know if there is anything I missed.  If it sounds good,
I will deploy the configurations and hooks to the production git
repository and let Martin be able to import the new OpenZFS codes
soon.

Best,
Li-wen

On Sat, Apr 24, 2021 at 4:24 AM Ulrich Spörlein <uqs@freebsd.org> wrote:
>
> Wouldn't vendor/openzfs/master simply be an alias for openzfs/master and
> it would be the pristine upstream source repo? Or do we have local
> modifications in our vendor/openzfs/master, if so, ignore me.
>
> On Fri, 2021-04-23 at 02:50:57 +0200, Martin Matuska wrote:
> >Hi Warner,
> >
> >thank you very much for the update.
> >
> >If I understand this correctly, the way to go in the future is a 1:1
> >merge from openzfs/master to e.g. vendor/openzfs/master and from
> >openzfs/zfs-2.1-release to vendor/openzfs/zfs-2.1-release? And as a
> >second step a subtree merge from vendor/openzfs/* to main or stable/13?
> >
> >Martin
> >
> >On 22. 4. 2021 20:34, Warner Losh wrote:
> >> Hey Martin,
> >>
> >> I just wanted to let you know we've been working towards enabling
> >> pushing vendor/openzfs/* branches. There's one big issue that needs to
> >> be corrected. Currently, we'll do one email per revision hash on such
> >> imports, so openzfs would generate ~10k emails, which would be
> >> undesirable. Li Wen is working on enabling one email per push for
> >> vendor/* which would eliminate this problem. We hope to be doing test
> >> pushes to the testing repo early next week, and if all goes well
> >> enabling this in production shortly after.
> >>
> >> IMHO, you've made a compelling case: the size is small, the coupling
> >> between the projects is tight and we get some extra benefit from
> >> having a finer-grained vendor branch that we import from. The plan to
> >> import directly from vendor/openzfs/zfs-2.1 would normally be
> >> concerning because it's not following the usual main -> stable/X
> >> workflow. In this case, though, since upstream follows that workflow
> >> we won't lose things that get pushed to stable/13 that aren't also
> >> relevant to main. There's at least some configuration needed to allow
> >> the merge commits to stable/13, but we're still working out the last
> >> details.
> >>
> >> So we'll be good to go soon (1-2 weeks until you can land commits, I
> >> think). Does that work for you?
> >>
> >> Warner
> >>
> >
> >_______________________________________________
> >freebsd-git@freebsd.org mailing list
> >https://lists.freebsd.org/mailman/listinfo/freebsd-git
> >To unsubscribe, send any mail to "freebsd-git-unsubscribe@freebsd.org"
> _______________________________________________
> freebsd-git@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-git
> To unsubscribe, send any mail to "freebsd-git-unsubscribe@freebsd.org"