Not-Forking (https://lumosql.org/src/not-forking ) avoids duplicating the source code of one project within another project, where the projects are external to each other. Not-forking avoids project-level forking by automating change management in ways that version control systems such as Fossil, Git, or GitHub cannot. Not-Forking can track multiple upstreams, each with a different release schedule, VCS and human-readable version numbering/lettering system.
This could be relevant to Debian because: 1. Not-Forking may help address the Debian small-scale vendoring problem (https://lwn.net/Articles/836911/ ) 2. Not-Forking may be useful to anyone creating Makefiles that assemble disparate codebases There is no Debian package for Not-Forking yet, although there is an ebuild in the current release 0.3.1. Examples of the sorts of actions Not-Forking can take: * check for new versions of all upstreams, doing comparisons of the human-readable release numbers rather than repo checkins or tags, where human-readable version numbers vary widely in their construction * replace foo.c with bar.c in all cases (perhaps because we want to replace a library that has an identical API with a safer implementation) * apply this patch to main.c of Upstream 0, but only in the case where we are also pulling in upstream1.c, but not if we are also using upstream2.c * apply these non-patch changes to Upstream 0 main.c in the style of sed rather than patch, making it possible to merge trees that a VCS says are unmergable * build with upstream1.c version 2, and upstream3.c version 3, both of which are ported to upstream 0's main.c version 5 * track changes in all upstreams, which may use arbitrary release mechanisms (Git, tarball, Fossil, other) * cache all versions of all upstreams, so that a build system can step through a large matrix of versions of code quickly, perhaps for test/benchmark Not-Forking was developed for the LumoSQL project, https://lumosql.org/src/lumosql . -- Dan Shearer d...@shearer.org