From owner-freebsd-git@freebsd.org Fri Apr 2 15:49:58 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6FBD557A9E5 for ; Fri, 2 Apr 2021 15:49:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FBkyY2RNRz3K0s for ; Fri, 2 Apr 2021 15:49:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x831.google.com with SMTP id 1so4007660qtb.0 for ; Fri, 02 Apr 2021 08:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6giM+jCYk8prOOKxw+eoPZ5soUCpZb1UdhxN0dUY59Y=; b=0tvXOUBMlYBAkrp/0srBdG5yfzyxdc8xEzgo5tD4UBW1F+NZLWPAgyql6BHnvmt1pG tA0Mxwn+uNjA6s52Ffsj/uJBRTYBO47YNXhdMMoDxxaLIsnISrzdzOTltf6407xg85cE RHgeB72nv0+OkOUOBYCL1RBoOzXj1O8exsngBkpWD4rsYo/ka+BwvQzvnVi2CVn/5eHo R1V79p32EwMsb4dukGsrXqdQRtz/Bqm7KiiNRTezaHfPrhzIedP9P6nROku1NTMyrsqE VihycNwDVQAcxWHyuZo3ILJnJChcBOLmYBJufBdLWZb/ehCY8cZ+2wg6oUaAwzCow8pE FVTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6giM+jCYk8prOOKxw+eoPZ5soUCpZb1UdhxN0dUY59Y=; b=shIUwgoRCXicuCe4M58u1sCraku6eeMw76yq9AVQXhOTUrTT9ocbXbZyfmLEJYdkps RDxZDXq5WiDVEQI/UQRx0mbW+5t0uQ1RPgyuTid3Ssf4AWzzWYDPmyFJyxlRHp4juwzf qWdd1Da6dou7LAkRzVR9kfws6YcVBOTT9SdHQ1WYKjdppMMg9OlX2HDffAM/8mefjEpo u2CyC61x+twEHbBlI+tUJAeb9p9Qt15bFBXjw+Q5sqnZ9BE1qAtliTz8X+zd3nfy94wo ydPbHzAgyxNVn7PkbKwZMwjjDOGufiWwHmckbAwCPy0Pp92GFKbQH9o6hpccXxupmTST 0CxQ== X-Gm-Message-State: AOAM530jp4ZOzMsED3hlLWmQ/5w8jm41QMAbnvLK4f8zEzcm0nPwRSCs FrjnZlAFXC2hQxb08qAnvYIDtfXSBsAfK4cgU7ST8gjjIZRPgg== X-Google-Smtp-Source: ABdhPJwlDfZ9+EUVCiMBI2i2oAzNYpChGMtNpcMSHOWvks5pCiLdLizNhoIRjRzj2VLWE5okY3gO86C62sZrdV1f8oo= X-Received: by 2002:a05:622a:1c5:: with SMTP id t5mr11560770qtw.49.1617378596035; Fri, 02 Apr 2021 08:49:56 -0700 (PDT) MIME-Version: 1.0 References: <21c7313e-315c-ec48-9437-e0a3d4ec14d2@FreeBSD.org> In-Reply-To: <21c7313e-315c-ec48-9437-e0a3d4ec14d2@FreeBSD.org> From: Warner Losh Date: Fri, 2 Apr 2021 09:49:45 -0600 Message-ID: Subject: Re: OpenZFS branch tracking policy To: Martin Matuska Cc: freebsd-git X-Rspamd-Queue-Id: 4FBkyY2RNRz3K0s X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=0tvXOUBM; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::831) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; MAILMAN_DEST(0.00)[freebsd-git]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::831:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::831:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::831:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 15:49:58 -0000 On Fri, Apr 2, 2021 at 4:02 AM Martin Matuska 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