Date: Sat, 3 Apr 2021 02:51:41 +0200 From: Martin Matuska <mm@FreeBSD.org> To: Warner Losh <imp@bsdimp.com>, Ed Maste <emaste@freebsd.org> Cc: freebsd-git <freebsd-git@freebsd.org>, Alexander Motin <mav@FreeBSD.org>, Mateusz Guzik <mjg@FreeBSD.org>, Ryan Moeller <freqlabs@FreeBSD.org> Subject: Re: OpenZFS branch tracking policy Message-ID: <323a07e2-beeb-deb3-3fa5-bd1241a2cb04@FreeBSD.org> In-Reply-To: <30f529c1-6087-e704-8cc7-0c48a40b7430@FreeBSD.org> References: <21c7313e-315c-ec48-9437-e0a3d4ec14d2@FreeBSD.org> <CANCZdfopOxm-HTYkVPHkEweHw-F%2BA9mk3Vv26x4t3MEAVEd2gQ@mail.gmail.com> <CAPyFy2DS=nsE3-JQdqQC797xQhAiBACkuyA%2BcxkcRY0yeB_6=w@mail.gmail.com> <CANCZdfoPm0tfDpBTU8ORy-_Oa-tkiNX0_MeAdJn0T5ZJdQe6MQ@mail.gmail.com> <41924e9d-9d61-6646-6c8f-e4458f94296e@FreeBSD.org> <30f529c1-6087-e704-8cc7-0c48a40b7430@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I have missed one more thing: Tracking different OpenZFS branches in main and stable/13 means that we=20 will be vendor-merging into stable/13 as well (opposed to cherry-picking)= . On 3. 4. 2021 2:44, Martin Matuska wrote: > I have prepared an example merged branch here: > https://github.com/mmatuska/freebsd-src/tree/openzfs_master_merged > > The magical command was: > git merge -s subtree -Xsubtree=3D"sys/contrib/openzfs" 891568c99=20 > --allow-unrelated-histories > > Luckily, our current diff is manageable. > > Martin > > On 3. 4. 2021 1:37, Martin Matuska wrote: >> Hi Warner and Ed, >> >> 2.1-release has already been branched. The stable branch policy in=20 >> OpenZFS is somewhat strange, they make a staging branch for each=20 >> patchlevel release, but the commits are continuous. >> >> To have some idea how big the repo history is: >> >> $ git rev-list master --count >> 6662 >> >> $ git rev-list zfs-2.1-release --count >> 6650 >> >> master and zfs-2.1-release have 6650 common commits at the moment >> >> $ git log master | wc -l >> 129868 >> >> (linecount - 4 * revcount) / revcount =3D linecount / revcount - 4 =3D= =20 >> 15,4938 comment lines per commit on average >> >> Initial commit was made in Feb 26, 2008. >> >> Yearly commit counts: >> >> $ git log master | grep -c -E '^Date:.* 2020 -[0-9]+$' >> 666 >> >> $ git log master | grep -c -E '^Date:.* 2019 -[0-9]+$' >> 535 >> >> $git log master | grep -c -E '^Date:.* 2018 -[0-9]+$' >> 428 >> >> Martin >> >> On 2. 4. 2021 20:15, Warner Losh wrote: >>> >>> >>> On Fri, Apr 2, 2021 at 11:56 AM Ed Maste <emaste@freebsd.org=20 >>> <mailto:emaste@freebsd.org>> wrote: >>> >>> =C2=A0=C2=A0=C2=A0 On Fri, 2 Apr 2021 at 11:50, Warner Losh <imp@bsdi= mp.com >>> =C2=A0=C2=A0=C2=A0 <mailto:imp@bsdimp.com>> wrote: >>> =C2=A0=C2=A0=C2=A0 > >>> =C2=A0=C2=A0=C2=A0 > We'd always hoped that we'd be able to do subtre= e merges from >>> =C2=A0=C2=A0=C2=A0 upstreams >>> =C2=A0=C2=A0=C2=A0 > that use git into FreeBSD. The big worry, though= , was that this >>> =C2=A0=C2=A0=C2=A0 would >>> =C2=A0=C2=A0=C2=A0 > needless bloat the repo with a lot of history. W= e don't want, >>> =C2=A0=C2=A0=C2=A0 for example, >>> =C2=A0=C2=A0=C2=A0 > all of LLVM's history in the tree. We'd always a= nticipated that >>> =C2=A0=C2=A0=C2=A0 there'd be >>> =C2=A0=C2=A0=C2=A0 > some things we'd just accept the history for, si= nce it is=20 >>> similar in >>> =C2=A0=C2=A0=C2=A0 > character to the vendor branches (though of cour= se a bit more). >>> >>> =C2=A0=C2=A0=C2=A0 Note that if we do want to avoid bringing in the f= ull history `git >>> =C2=A0=C2=A0=C2=A0 subtree merge` supports a `--squash` option. This = brings in the=20 >>> set of >>> =C2=A0=C2=A0=C2=A0 upstream changes as a single commit, without bring= ing along the >>> =C2=A0=C2=A0=C2=A0 associated history. We will need to do more experi= mentation to=20 >>> confirm >>> =C2=A0=C2=A0=C2=A0 that the full process, including bootstrapping, wi= ll work as we=20 >>> want. >>> =C2=A0=C2=A0=C2=A0 Assuming this all works it should allow us to forg= o the use of a >>> =C2=A0=C2=A0=C2=A0 FreeBSD-specific vendor branch in src. >>> >>> =C2=A0=C2=A0=C2=A0 We've discussed mirroring any such 3rd-party sourc= e in some >>> =C2=A0=C2=A0=C2=A0 FreeBSD-controlled repository. This would allow th= e project to=20 >>> retain >>> =C2=A0=C2=A0=C2=A0 a full copy of the history, but avoid bloating src= with it. >>> >>> =C2=A0=C2=A0=C2=A0 I agree with Warner that we may want a different p= olicy (full=20 >>> history >>> =C2=A0=C2=A0=C2=A0 or snapshots) for different contrib sources. >>> >>> >>> Good points Ed. I'd forgotten about --squash. >>> >>> Martin, what's your timeline for wanting to implement these things?=20 >>> I'm unfamiliar with the OpenZFS schedules. >>> >>> 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?323a07e2-beeb-deb3-3fa5-bd1241a2cb04>