Date: Tue, 8 Jun 2021 06:29:51 +0800 From: Li-Wen Hsu <lwhsu@freebsd.org> To: freebsd-git <freebsd-git@freebsd.org> Cc: Martin Matuska <mm@freebsd.org>, =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= <uqs@freebsd.org>, Warner Losh <imp@freebsd.org>, Xin LI <delphij@freebsd.org> Subject: Re: OpenZFS imports, status update Message-ID: <CAKBkRUxeoPwW1ZgwL13=8XkgJv9z8Y55h1TuU8SYoN_0w0qbUQ@mail.gmail.com> In-Reply-To: <YIMtD4SA9e9VTsez@acme.spoerlein.net> References: <CANCZdfrM5rKo6AKhHMCbp3O8ZoxqCkGNT3aRrSwE%2B6HzS7MDJA@mail.gmail.com> <aed58350-a351-7fb0-ee22-daa6d41ed2c9@FreeBSD.org> <YIMtD4SA9e9VTsez@acme.spoerlein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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=C3=B6rlein <uqs@freebsd.org> wrot= e: > > 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKBkRUxeoPwW1ZgwL13=8XkgJv9z8Y55h1TuU8SYoN_0w0qbUQ>