OpenZFS branch tracking policy

[Martin Matuska]

Hi Warner and Ed,

2.1-release has already been branched. The stable branch policy in 
OpenZFS is somewhat strange, they make a staging branch for each 
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 = linecount / revcount - 4 = 
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 at freebsd.org 
> <mailto:emaste at freebsd.org>> wrote:
>
>     On Fri, 2 Apr 2021 at 11:50, Warner Losh <imp at bsdimp.com
>     <mailto:imp at bsdimp.com>> wrote:
>     >
>     > 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).
>
>     Note that if we do want to avoid bringing in the full history `git
>     subtree merge` supports a `--squash` option. This brings in the set of
>     upstream changes as a single commit, without bringing along the
>     associated history. We will need to do more experimentation to confirm
>     that the full process, including bootstrapping, will work as we want.
>     Assuming this all works it should allow us to forgo the use of a
>     FreeBSD-specific vendor branch in src.
>
>     We've discussed mirroring any such 3rd-party source in some
>     FreeBSD-controlled repository. This would allow the project to retain
>     a full copy of the history, but avoid bloating src with it.
>
>     I agree with Warner that we may want a different policy (full history
>     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? 
> I'm unfamiliar with the OpenZFS schedules.
>
> Warner