From owner-freebsd-git@freebsd.org Fri Apr 16 19:27:38 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 5F0645DCAE0 for ; Fri, 16 Apr 2021 19:27:38 +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 4FMR7F4sGgz4l4N for ; Fri, 16 Apr 2021 19:27:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x831.google.com with SMTP id f12so21624177qtf.2 for ; Fri, 16 Apr 2021 12:27:37 -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=vb4mQNpSezj3Gm5S80MJRzW1uslXBKHX1vk7O5ziviE=; b=Isj2KzlR4hAIX0NqB3giiGTB60eCs9vPmUcVnuQ7PwQ25DykqhPqlK2dJBKm/Pelef xhSKjbSSKddQoXKr950CyYbP5xMOrViTa4vpeUbNHuMkcO/oWh3R4RX6WCYCZgYBSlmr 8v5CPyGLFyMw9LF6CVBCdZTCeIbiBc3WfXxDtDHvSIkuoCCAB/fHI0FqFsjkdPzVygN/ 4KnjPh7jK+LRIOVcUFB2JoD6phTTus8MstA3g2n/6/Jlw7gZXV4pZU/RAxB8I4VVPj4G 97j+vqRID3GixtQZn1YwGJj0tdjclZ15hYuIwsicN8GWyqwMzMIW5NFjwAl2Pq0e2mHU 5nkg== 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=vb4mQNpSezj3Gm5S80MJRzW1uslXBKHX1vk7O5ziviE=; b=CZab6DdNp7IawaWv6mXIxpQdE1T0v8eKMW2ZBNpCq5VJT7eiEK4wAJWQdrnKXT8xBz Ex7eTjOSl3CYjjNMsWhLzg4/7uhM+f/MEPU2BIclCsCm/imlYSsBQFxy3X0t/WPzK0mI 9vbyJJuIK4wSmz3QcwA6uVcnV9iTPGIlrHTBUqDT4+TAteJ5zPK5wSnq1tnagWKHI3US CkTBmJXBEG2EdtJLnvChVMonqmSZyb5dMljS6bqaCSGZSuhSUHPLrUyP/J5/ZgWK3CNd sry9pjVmtTTcDBFKvll+zFitxOETxGMZSTrOGvq+g11QkWLy3F6Q/N4uVt0DgVZlW9o+ EFbw== X-Gm-Message-State: AOAM530zTOFuDMtmxfyA2C8sCE9JbmXVRRc+FPpSiZWEp4VkTe+N0U41 fq6xl680gbOhjYmBTePI2pfT6kyUaYIo0rTeNbrOWg== X-Google-Smtp-Source: ABdhPJyna4v+KSiH0q7oxdJ9Q3e6KviZ7VZSj5bPKM4AEuzQnmRQl6/gHq5bOAAIuZAkqz1DzjqXF/iqykxH1jXfQsk= X-Received: by 2002:ac8:7e95:: with SMTP id w21mr673978qtj.244.1618601256259; Fri, 16 Apr 2021 12:27:36 -0700 (PDT) MIME-Version: 1.0 References: <41924e9d-9d61-6646-6c8f-e4458f94296e@FreeBSD.org> <30f529c1-6087-e704-8cc7-0c48a40b7430@FreeBSD.org> <9679ec9d-4916-92b7-ff70-0050d699875c@FreeBSD.org> <2b404ead-d862-c4ba-41cd-4ceb1246ce6f@FreeBSD.org> In-Reply-To: <2b404ead-d862-c4ba-41cd-4ceb1246ce6f@FreeBSD.org> From: Warner Losh Date: Fri, 16 Apr 2021 13:27:25 -0600 Message-ID: Subject: Re: OpenZFS branch tracking policy To: Martin Matuska Cc: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= , Mateusz Guzik , Ryan Moeller , Alexander Motin , freebsd-git X-Rspamd-Queue-Id: 4FMR7F4sGgz4l4N X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=Isj2KzlR; 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 [-0.99 / 15.00]; ARC_NA(0.00)[]; MAILMAN_DEST(0.00)[freebsd-git]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; 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]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_FIVE(0.00)[6]; 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:+]; NEURAL_HAM_SHORT(-0.99)[-0.991]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::831:from]; 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]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 16 Apr 2021 19:27:38 -0000 On Fri, Apr 16, 2021 at 1:24 PM Martin Matuska wrote: > Thank you guys for your input. > > OpenZFS 2.1 has already gone -RC3, eliminating even more diffs the code i= n > 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 matte= r > 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 eve= n > 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 bran= ch > 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=C3=B6rlein wr= ote: > >> 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=3Dsys/contrib/openzfs" from the >> >vendor branch be a better way to go than "git merge >> >-Xsubtree=3Dsys/contrib/openzfs"? Especially for stable/13, where I hav= e >> >to "merge" in the whole new vendor/openzfs/zfs-2.1-release branch. >> > >> >mm >> > >> >On 12. 4. 2021 11:02, Ulrich Sp=C3=B6rlein 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 t= o >> >>> 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 an= d >> >>> 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 w= e >> >> have developers working on contrib software, so the slight convenienc= e >> >> 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 >> >