Date: Fri, 2 Apr 2021 09:49:45 -0600 From: Warner Losh <imp@bsdimp.com> To: Martin Matuska <mm@freebsd.org> Cc: freebsd-git <freebsd-git@freebsd.org> Subject: Re: OpenZFS branch tracking policy Message-ID: <CANCZdfopOxm-HTYkVPHkEweHw-F%2BA9mk3Vv26x4t3MEAVEd2gQ@mail.gmail.com> In-Reply-To: <21c7313e-315c-ec48-9437-e0a3d4ec14d2@FreeBSD.org> References: <21c7313e-315c-ec48-9437-e0a3d4ec14d2@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 2, 2021 at 4:02 AM Martin Matuska <mm@freebsd.org> wrote: > Dear git working group, > > OpenZFS 2.1 is approaching and there is an ongoing discussion between > the ZFS developers regarding branch tracking. > > What we want archieve: > > FreeBSD main will be tracking the master branch of openzfs/zfs > FreeBSD stable/13 will be tracking the zfs-2.1-release and upcoming > staging branches of openzfs/zfs (they always have continuous commits) > > At the moment, I rsync changes from openzfs/zfs to our vendor/openfzfs > and commit them. > > The question is, if this is the correct way to do this? > OpenZFS uses git so we might skip vendor/openzfs and subtree merge > directly from openzfs/master (and that way inherit all OpenZFS history) > and openzfs/zfs-2.1-release. That would be way easier to manage and we > can track and see "real" commits from OpenZFS. > > The other way would be like now, keep two vendor branches and rsync, but > that makes it harder to track. > > I would be really happy for a decision so I can start merging > zfs-2.1-release. > We'd anticipated this need. But have some questions. The first question is: do you have a concrete set of instructions for how you plan on doing this written up yet? It's not necessary, but if you did I could comment on things in more detail. We'd always hoped that we'd be able to do subtree merges from upstreams that use git into FreeBSD. The big worry, though, was that this would needless bloat the repo with a lot of history. We don't want, for example, all of LLVM's history in the tree. We'd always anticipated that there'd be some things we'd just accept the history for, since it is similar in character to the vendor branches (though of course a bit more). So the first question I have is what's the rate of commits to OpenZFS? If you were to do the above in the straightforward way, then our repo grows at a rate that's the sum of both projects. If it is low enough, the straightforward way is likely the best way, though with some kind of explicit guidance on what's "too much" or "too big". We'll also need to manage the upstream branch naming somehow. I think we should talk to uqs@ before we do anything because he's got a much better handle on the subtle issues that will arise and can recommend something reasonable there. Ditto any tags we want to import from upstream, should we go this route. We'd talked about ways of even doing this with LLVM in some way that would push the merge commits w/o pushing all the history to the central repo with explicit instructions for others that wish to do the next one in case that person changes. We'd thought there'd be a role for some aux repo to act as a staging area for some of this so we needn't bloat the main repo. A 'vendor repo' that's a refinement of the 'vendor branch' we now are using with some kind of guard to prevent the 'vendor repo' from seeping into the main repo. But the notions we talked about were vague and we never proceeded beyond talk in how to cope with a future where people want to do the sorts of things you are talking about. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfopOxm-HTYkVPHkEweHw-F%2BA9mk3Vv26x4t3MEAVEd2gQ>